《云计算与虚拟化技术丛书 Service Mesh实战》—1.2技术架构演进

1.2　技术架构演进

       当单体应用拆分为微服务后，新的通信模型如图1-2所示。

       图1-2　微服务构成

       如图1-2所示，每个微服务由2部分构成。

       业务逻辑：定义如何处理应用业务逻辑。

       网络功能：网络功能部分主要负责服务间的通信，包括上述列出的构建分布式高可用的技术实现，如超时、重试、服务发现、负载均衡等，由于它基于下层网络协议栈实现，因此被称作网络功能。

       相对于传统的单体应用，网络功能部分可以通过一个中心化的组件来统一实现或者直接嵌入到业务逻辑中，但是在微服务架构中，服务的粒度变得更小，为了实现它们之间的可靠通信，开发人员为每个微服务实现网络功能比实现业务逻辑花费的时间和精力可能更多。最初，开发人员把上述的一些技术手段如负载均衡、服务发现或熔断等跟业务逻辑代码一起封装起来，使得应用具有处理网络弹性的能力。

       图1-3中的这种方案非常简单，易于实现，但从软件设计的角度，大家很快发现它有以下缺点。

       耦合性很高，每个应用都需封装负载均衡、服务发现、安全通信以及分布式追踪等功能。

       灵活性差，复用率低下，不同的应用需要重复实现。

       管理复杂，当其中一项如负载均衡逻辑发生变化，需要更新所有服务。

       可运维性低，所有组件均封装在业务逻辑代码中，不能作为一个独立运维对象。对开发人员能力要求很高。

图1-3　传统架构

       关于上述方案，应用已具有处理网络弹性能力，及动态运行环境中处理服务发现、负载均衡等能力，向提供高可用、高稳定性、高SLA应用更进一步，与此同时，你也看到这种模式具有很多缺点。为此，我们是否可以考虑将应用处理服务发现、负载均衡、分布式追踪、安全通信等设计为一个公用库呢？这样使得应用与这些功能具有更低的耦合性，而且更加灵活、提高利用率及运维性，更主要的是开发人员只需要关注公用库，而不是自己实现，更多地关注业务逻辑，从而降低开发人员的负担。这方面很多公司如Twitter、Facebook等走在业界前列，像Twitter提供的可扩展RPC库Finagle、Facebook的C++ HTTP框架Proxygen、Netflix的各种开发套件，还有如分布式追踪系统Zipkin, 这些库和开发套件的出现大量减少重复实现的工作。对于这种模式如图1-4所示。

       虽然相对前一种解决方案，新的方案在耦合性、灵活性、利用率等方面有很大的提升，但是仍然有些不足之处。

       如果将类似Finagle、 Proxygen或者Zipkin的库集成现有的系统中，仍然需要花费大量的时间、人力将其集成到现有生态圈，甚至需要调整现有应用的代码。

图1-4　基于公共库的架构

       缺乏多语言支持，由于这些库只针对某种语言或者少数几种语言，这使得在一个多技术栈的公司中需要限制开发语言和工具的选择。

       虽然公共库作为一个独立的整体，但在管理复杂性和运维性这些方面仍然有更大的提升空间。

       公共库并不能完全使得开发人员只关注业务代码逻辑，仍然需要对公共库有很深的认识。

       显然，没有任何方案能一劳永逸地解决所有的问题，而各种问题驱使技术人员不断地向前演进、发展，探索新的解决方法。那么，针对现在所面临的问题，我们有更好的解决方案吗？答案是肯定的。相信大家对OSI七层模型应该不陌生，OSI定义了开放系统的层次结构、层次之间的相互关系以及各层所包括的可能的任务，上层并不需要对底层具体功能有详细的了解，只需按照定义的准则协调工作即可。因此，我们也可参照OSI七层模型将公用库设计为位于网络栈和应用业务逻辑之间的独立层，即透明网络代理，新的独立层完全从业务逻辑中抽离，作为独立的运行单元，与业务不再直接紧密关联。通过在独立层的透明网络代理上实现负载均衡、服务发现、熔断、运行时动态路由等功能，该透明代理在业界有一个非常新颖时髦的名字：Service Mesh。率先使用这个Buzzword的产品恐怕非Buoyant的Linkerd（https://linkerd.io/）莫属了，随后Lyft也发布了他们的Service Mesh实现Envoy（https://github.com/envoyproxy/envoy），之后Istio（https://istio.io/）也迎面赶上，成为Service Mesh领域非常热门的一个项目。新的模式如图1-5所示。

图1-5　基于Service Mesh的架构

       在这种方案中，Service Mesh作为独立运行层，它很好地解决了上述所面临的挑战，使应用具备处理网络弹性逻辑和提供可靠交互请求的能力。它使得耦合性更低、灵活性更强，跟现有环境的集成时间和人力代价更小，也提供多语言支持、多协议支持，运维和管理成本更低。最主要的是开发人员只需关注业务代码逻辑，而不需要关注业务代码以外的其他功能，即Service Mesh对开发人员是透明的。