李磊 刘相 李航

海量的请求、庞大的数据、不断推陈出新的业务，从各个方面促使企业进行IT建设升级。微服务架构被认为是未来建设新一代分布式架构应用的方向，可以更容易升级和扩展，并部署在云环境中。

随着数字化转型的迅猛发展，公司、组织业务不断扩张，需求爆炸式增长、用户量不断增加，传统单体架构已经无法适应云计算环境下的快速变化。海量的请求、庞大的数据、不断推陈出新的业务，也在从各个方面促使企业进行IT建设升级。微服务架构被认为是未来建设新一代分布式架构应用的方向，通过将应用和服务分解成更小的、松散耦合的组件，微服务架构可以更加容易升级和扩展，并部署在云环境中。

但企业在建设新一代分布式架构应用时遇到了新的问题，这些问题困扰着企业的数字化转型。

分布式架构跨越内部网络、外部网络，从內部系统间的服务通信编排，流转到外部服务调用。如何保证数据的一致性？面对层出不穷的各种架构解决方案，如何验证并适应市场快速的变动？如何快速收集市场需求并将之有效地传达给开发部门，服务上下线？整个生命周期运维团队如何适应新的分布式应用？

一方面，分布式系统的建设对需求、研发、测试和运维等环节带来了诸多新的挑战，企业迫切需要一套工程化的敏捷交付方法来支撑微服务应用建设的各个阶段，加速云应用的交付。另一方面，分布式架构应用的建设较原来的单体应用更加复杂。大量业务系统逐步走向分布式的同时，企业应用也更多的从服务内部用户逐步转向为服务外部客户。在这个转变的过程中暴露出了各种各样的问题。

分布式中间件的迅猛发展可以协助企业进行数字化转型，但分布式中间件本身还处于不断完善升级的过程，无法满足企业业务快速变化的诉求，进而影响了企业数字化转型的步伐。

分布式系统建设的痛点与诉求

从单节点应用向分布式应用改造时，我们会发现业务代码与技术组件是一种强耦合关系。如在网络方面进行调用时，业务代码要大量耦合各种网络调用的服务，此时就存在问题—如果中间件服务发生了变化，业务应用也需要相应的进行改造。此外，在集成层面，业务的处理需要跨多个系统进行调用，此时会依赖企业服务总线等中间件进行服务的编排，这种编排也强耦合在业务代码中。这些原因导致了业务代码与中间件服务之间的强耦合关系，导致任何一方的升级或者变化都会直接影响到对方。因此针对分布式应用建设的核心痛点是不同服务间的网络通信。

除网络通信外，在分布式应用系统建设过程中还会涉及业务集成、状态管理、生命周期等维度，下面我们将从这四个维度分析分布式应用对分布式中间件带来的挑战，找到其中的关键因素，探索分布式中间件的诉求。

网络通信

分布式应用基于其架构特点，需要做到：能够方便地进行本身的注册，可以让其他应用了解这里所具有的服务能力，并让对方进行调用。在注册的同时，能发现分布式体系中的其他服务，并且可以根据实际业务的不同，将数据通过业务路由发送到正确的服务节点并获取相关数据。在整个分布式体系中，需要确保网络的可用性，业务层需要响应业务请求，而分布式中间件本身要完好地支撑业务网络间的信息通信安全，比如保障数据加密安全等。此外，分布式应用还需要拥有完善的可靠保证，在运行期间根据业务量、网络情况、服务负载能力进行自动化调整，避免被“浪涌”冲垮，或者在长时间请求无法得到响应的情况下执行多种的重试机制，以保证整体服务链路的可用性。

目前，分布式应用开发、网络通信基础能力均是依赖分布式中间件的开发框架。分布式中间件能够提供的能力越来越丰富，并且支持在运维期进行各种网络策略的调整、业务路由的配置等。但开发人员被分布式中间件开发框架束缚，如果企业采用了某种特定的分布式开发框架，则在业务代码中不可辨免地导致分布式应用与提供网络通信能力的分布式开发框架强耦合，使得开发人员不能聚焦在业务处理上。

业务集成

分布式应用一方面涉及企业内部的多系统、多业务请求，另一方面也会调用外部服务，导致大量的服务编排。由于各种历史原因，不同的系统可能采用了不同的通信协议、报文格式，它们需要在服务编排过程中，对不同的协议、报文格式进行编码转换。固然现在多数的企业服务总线提供了灵活的配置，但仍有大量的编排工作需要开发人员处理。

此外，企业还需要在分布式应用内考虑大量非功能性的场景，比如事务一致性、可靠机制、出错后的重试、异常处理等多种技术上的复杂情况。例如客户在进行一次性涉及多个商家的交易时，会与不同的金融机构进行通信，在整个交易过程中，需要从全局考虑，保证业务整体的一致性，确保整个交易链路的通畅。

状态管理

状态管理是分布式应用的核心，分布式应用考虑到云原生的需求，需要保证应用的无状态性，但实际的业务应用存在大量的状态数据，需要将应用的各种状态数据剥离并保存在多种分布式缓存中间件中。同时分布式应用实现幂等操作，保障分布式应用同一笔业务在多次调用的情况下可以返回同样的处理逻辑。另外考虑到分布式应用业务流程状态的管理，需要依赖大量的流程中间件进行工作项的管理。分布式应用需要通过各种SDK与分布式缓存中间件或者流程中间件进行耦合式的交互，以完成业务的诉求。

生命周期

在数字化转型过程中，企业从单独运维部门对单体应用的集群管理转向了虚拟化、云化、分布式架构的管理。这需要从需求到部署上线的软件生产线都满足分布式应用的自动化发布与配置。同时需要将线下IT生产过程转变为线上高度自动化、可视化的IT生产线，提升IT系统研发效率，快速响应业务需求。

在业务上线的过程中，同样会存在各种异常情况，这就要求企业对分布式应用进行实时的健康监控，使发生生产故障时可以进行实时或者准实时的故障恢复处理。同时分布式应用也不同于以往的单体应用，分布式应用多运行在云环境中，需要有更方便的方式对分布在各个节点上的微服务应用进行统一的配置管理，在不影响业务使用的同时，进行配置的更新。同时在运行阶段，企业从成本角度和服务的高可用性上也需要能够进行分布式应用的自动伸缩，在大并发的情况下，根据业务规则实时进行服务节点的自动伸缩。

下一代分布式中间件的建设之路

通过分布式应用的痛点分析，总结出分布式应用的三点建设诉求。

1.分布式中间件需要像水电煤一样，作为基础服务能力，随时被分布式业务应用进行自助化调用，降低分布式业务应用对分布式中间件的使用复杂度。

2.分布式应用需要为分布式业务应用的全生命周期管理提供更加便捷、智能的管控环境，以支撑分布式应用的全生命周期管理，包括需求、项目、代码、持续集成、持续发布、运维、监控等。

3.业务和底层框架应该是解耦的，并且能通过快速扩展的能力，在不改变服务代码的情况下添加、升级、删减分布式中间件的底层能力，并根据业务的需要快速便捷地选择相应的分布式中间件来为分布式应用服务。

基于分布式中间件建设的后续IT建设，将持续关注如何更加便捷地让业务应用和分布式能力进行解耦，企业如何更好地根据自身需要快速搭建出符合自身需求的企业平台。下面，我们从自助化、敏捷化、多Mesh化三个方向来探讨下一代分布式中间件的建设方向。

自助化

企业中间件将会逐步向云化发展。分布式应用所须的各种资源需要能够自助化的获得。在云平台上，可以做到根据业务情况按需申请，即开即用。除了基础功能的快速满足外，企业中间件还能够按照业务应用的请求量、运算量，智能化地进行集群高可靠的自助开通。最终做到让分布式中间件能够简单的被获取。在业务运行时，分布式中间件能够快速注册开通、服务试用，并能够提供多种使用策略：在闲时减少资源试用，降低成本花销;在忙时动态伸缩，增强业务处理能力。

敏捷化

在IT建设数字化转型的过程中，企业会重新梳理自身，不断发现自身在整个软件体系工程中可以优化改进的点—从调研与评估、建设方案规划、实施落地三个阶段逐步推进，建立企业生产线DevOps平台，覆盖从需求到运营的大生产阶段，打通企业IT全生命周期的数据链路。

业务应用要对需求、开发、测试、部署进行一站式的协同，同时沉淀全生命周期的研发过程数据，通过数据分析，实现对研发过程的度量和改进。企业要屏蔽线上线下环境差异，轻量化部署，提升业务上线效率，自动监听调度，增强业务系统的稳定性和可用性，支持更大密度的混合部署，提高资源利用率，降低整体运营成本。

多Mesh化

目前业界在分布式系统当中，解决分布式系统跨通信、强耦合的一个比较好的解决方案是服务网格Service Mesh技术。

Service Mesh在两个服务调用中引入了Proxy（Side car）进行网络代理，服务A要调用服务B时，首先要通过服务A的Proxy请求服务B的Proxy，然后通过服务B的Proxy请求回到服务B，进行访问响应。通过Proxy，Service Mesh解决了网络中的透明性问题，这样服务本身的业务代码变动对底层的网络是无感知的。同时Service Mesh架构除了解决http网络通信问题之外，还能支撑多种异构微服务间的交互。Service Mesh将底层中间件的能力做成SideCar，微服务通过不同SideCar进行通信，解决了与业务代码强耦合的问题。

Service Mesh的实现主要是通过在网络通信层提供透明化的服务代理，为每个微服务提供了1∶1的代理模式，即为每一个微服务提供一个SideCar，实现了对网络请求的自动化拦截与代理，从而降低了分布式应用开发的复杂度。原有Service Mesh的核心问题包括：只解决了网络通信层的代理，没有涉及分布式应用的其它维度;每个微服务必须单独配置一个服务代理，没有提供代理的共享机制;业务应用无法按需选择分布式中间件的服务能力。

借鉴Service Mesh的设计思想，多Mesh化的分布式中间件平台将代理从当下的网络通信层扩展到业务集成、状态管理、生命周期等维度，分别提供不同维度的SideCar来实现业务应用与分布式中间件的解耦。同时，将不同维度的SideCar通过聚合的方式形成新的分布式能力SideCar平台，对外可以通过提供声明式、配置式、可自由组合分布式服务的能力为分布式业务应用提供服务。

多Mesh化的分布式中间件平台，提供网络通信SideCar、状态管理SideCar、业务集成SideCar、生命周期SideCar能力。同时为一个微服务应用提供多个Sidecar，根据需要，一个Sidecar可以服务多个微服务。

多Mesh化的分布式中间件平台，除了带给Mesh本身开箱即用的分布式能力这一优秀特性外，还提供了控制面板，为分布式应用提供声明式的配置，允许分布式应用通过配置的方式声明需要使用哪些分布式能力。同时，多Mesh化的分布式中间件平台对外提供标准的交互协议，采用HTTP+JSON的方式与分布式应用交互，以支持异构的分布式应用系统便捷的使用提供的分布式能力。多Mesh化的分布式中间件平台通过提供多种能力的SideCar实现了分布式业务应用与各种分布式能力的无缝解耦，让业务开发人员彻底专注于业务的开发中。此外，多Mesh化的分布式中间件平台能够使分布式中间件与分布式应用按照自己的业务进程发展，互不影响，并且可以随时根据业务需要，添加业务需要使用的其他分布式能力。

多Mesh化的分布式中间件平台解决了ServiceMesh的几个局限性问题并提供网络通信、业务集成、状态管理、生命周期四个维度的代理，支撑完整的分布式能力;提供代理共享的机制，每个代理可以支持多个分布式应用;提供统一的控制面板，支持业务应用按需配置分布式中间件服务能力。

在分布式系统建设过程中，分布式应用出现的强耦合、网络问题、集成问题等痛点，引出了分布式中间件建设的诉求。分布式中間件的未来建设方向是为了满足分布式应用的诉求，实现分布式中间件能力的透明化，无侵入地支撑分布式应用快速发展。