我们一起分析IT系统应用开发的发展趋势

作者：逸言 2022-03-03 08:15:19

云计算

云原生 了解云原生技术体系，一些耳熟能详的技术术语扑面而来，容器，微服务，服务网格（Service Mesh），包含了FaaS（函数即服务）和BaaS（后端即服务）的无服务器（Serverless）模式，都是技术架构常常采用的模式。

毫无疑问，云原生技术已经在事实上成为了大多数IT系统需要迈向的目标，区别只在于，到底是从一开始就遵循云原生架构原则对系统进行设计，还是演进式地从传统架构迁移到云原生架构。

了解云原生技术体系，一些耳熟能详的技术术语扑面而来，容器，微服务，服务网格(Service Mesh)，包含了FaaS(函数即服务)和BaaS(后端即服务)的无服务器(Serverless)模式，都是技术架构常常采用的模式。

分析这些技术术语，剖析它们的架构思想与落地实践，我希望从中窥得几分端倪，做一次关于IT系统应用开发的发展趋势分析。

1.趋势一：业务与技术的正交性越来越明显

云原生架构本身就是从技术角度出发，遵循云原生架构原则和模式，将云应用中的非业务代码进行最大化剥离，然后将其下沉到云服务(设施)平台，并以无侵略的方式和业务“粘合”在一起，共同支撑整个应用的运行。

设计上，为了避免业务复杂度和技术复杂度之间的互相干扰，设计上本来就需要力求业务与技术的正交性。随着云原生技术的逐渐成熟，剥离技术功能，保留业务代码的纯粹性成为可能。在云原生平台之上，业务系统的开发人员可以将精力放到业务领域的设计与开发，忽略运行过程中需要赋予系统的技术能力。

理想状态下，新的IT架构形态会形成：

• 设计态与研发态：关注点在于业务
• 运行态和运营态：关注点在于技术

如此就可能影响整个IT行业。由专业的云原生平台或微服务平台软件供应商打造和实施基于云原生架构的技术平台，提供基础设施服务，由垂直领域的传统企业IT部门与项目型软件供应商负责业务功能的实现，共同合作完成企业IT系统的构建，这可能是未来长期存在的IT生态现象。

开发人员的角色随之发生变化，业务型开发人员与技术型开发人员的分工变得越来越明显，需要的技能存在非常大的差异，前者更看重领域知识、抽象建模能力与设计能力，后者更看重底层的关键开发技术，掌握如网络通信、并行开发、数据一致等通用技术功能的实现。

2.趋势二：业务单元的粒度变得无关紧要

如果保证了业务与技术的正交性，意味着随着IT技术的发展，最终会打通制约软件开发的技术瓶颈。当我们可以不用考虑性能和安全，不用担心分布式通信的不可靠性，不用考虑分布式事务该如何保证一致性……业务单元的划分就不再干扰或影响整个应用的质量属性(非功能性需求)，反过来，系统的质量属性也不会影响对业务单元的划分。我们完全可以从纯业务角度出发定义业务单元的粒度。

如果业务场景复杂，又具有独立性和特殊性，将其设计为一个粗粒度的宏服务(macro service)也未尝不可;如果一个业务场景只需要系统提供单一的功能，自然可以设计为微服务(micro service)或者迷你服务(mini service);如果只是对单一数据进行运算或操作，不妨定义为一个云函数。

显然，当分布式通信等基础设施不再成为干扰因素时，各种粒度单元的组合会变得更加自由，一切只为具体的业务场景。

3.趋势三：传统调试技术受到挑战

在未来的应用系统，函数和事件会成为最主要的业务逻辑封装单元，事件驱动架构风格会变得越来越普遍。同时，技术关注点主要以代理(Sidecar)形式透明地“粘合”业务代码，使得代码的执行顺序不再是顺序式的，而是跳跃式的;执行的指令也不一定运行在同一个进程(或线程)。

这就使得本地环境的开发调试变得越来越困难，越来越复杂，由于模拟技术无法达到真实生产环境的效果，而业务逻辑和技术逻辑之间的“粘合剂”又非显式的胶水代码，使得现有IDE支持的传统调试和断点功能无法满足云原生时代的要求，至少增加了调试的成本，进而影响开发效率和开发质量。

为了迎合这一变化，除非能改进IDE的调试功能，在开发实践上应更加重视自动化测试，充分利用单元测试验证业务功能的正确性，由集成测试负责验证业务与技术结合后形成的完整功能。换言之，开发团队应尽可能通过自动化测试而非断点调试来发现问题。

4.趋势四：由业务人员开发核心业务代码

在分离了业务和技术之后，为了提升业务开发人员的效率，IT公司或部门需要对业务代码开展共性和可变性分析，识别并抽象出约80%业务逻辑的共性，将其沉淀为业务组件、微服务或云函数、甚至低代码平台，如此，开发人员就能将主要精力放在20%的差异化实现上。

因此，未来的业务系统开发会形成不同复用粒度和不同复用目标的多层次松耦合架构：技术关注点作为基础设施层，交由云原生平台形成技术支撑;组件、服务或函数组成的业务平台实现通用子领域与支撑子领域的所有功能，以及实现核心子领域的部分功能，并由低代码平台搭建(创建)脚手架、服务模板，完成不同粒度业务单元的组装;最后，在平台上编写定制的业务代码以满足业务逻辑的差异性。

由于只需编写核心的业务代码，DSL(领域特定语言)可能会成为各个垂直领域IT应用开发的首选，并以脚本方式在完成编写后注入到服务模板中。DSL风格的脚本对于业务人员更友好，它会慢慢侵蚀开发人员的空间。前面所述的业务开发人员要么转变为业务人员，要么参与测试和调试工作，成为质量保障团队的一员。

以上趋势有宏观层面，也有微观层次，不过是我偶然的想到，并非专业严谨的论断。定有疏漏之处，写来贻笑大方，只是随意记录我的想法罢了，但求读者不要苛责太甚。