微服务和 Serverless 架构-微服务架构和微服务框架

开发者学习笔记【阿里云云原生助理工程师认证（ACA）课程：微服务和 Serverless 架构-微服务架构和微服务框架】

课程地址：https://edu.aliyun.com/course/3112075/lesson/19024

微服务和 Serverless 架构-微服务架构和微服务框架

内容介绍

一、微服务架构的出现

二、微服务去中心化服务调用方式

三、初步微服务化改造后引发的新问题

四、微服务架构内部组件的关系

五、微服务架构的优劣总结

六、下一代微服务框架 Server Mesh

一、微服务架构的出现

在 SOA 推出大约 10 年之后，陆陆续续有一些软件架构的先驱者开始探索下一代新的分布式架构的样貌，其中比较有影响力的一位是 fred George ，他在 2012 年分享了他所在团队的新型服务架构体验，提出了模块微型化的概念，在架构中，他利用卡夫卡消息队列代替 ESB 就总线对模块进行解析，将传统的 100 万行支出一一代码通过解耦自动化等方式逐步分解成了 20 多个 5000 行代码的服务，整体代码量缩小了 10 倍，之后又将代码再次分解成了 200 多个 500 行代码的服务，实现了模块的微型化，这 500 行左右的微型化模块在测试开发部署上都变得非常的灵活轻便，具有了现代微服务架构的雏形。
在 2014 年的时候，另外两个架构界的前辈在 SOA 的架构上提出了一种新的微服务软件架构，这种架构已经非常贴近今天企业级应用通常采用的微服务架构，其中马丁弗瑞在他的著作当中为这种服务做了说明，并总结了大量的特性，其中服务组件化去中心化简单协议直接连接产品方式组织开发基础设施自动化的理念，深刻地影响了后来的微服务架构。
相比较于 soa 架构，微服务架构的最大技术特点是抛弃了中心化的 ESB 总线，而采用服务注册中心为服务调用者和服务提供者提供最基本的交流手段。

二、微服务去中心化服务调用方式

在微服务架构中服务提供者在上线的时候会首先向注册中心注册自己的地址以及所能提供的服务能力，而服务调用者在需要远程请求的时候会先通过注册中心查询对应服务提供者的地址，一旦服务调用者获得服务提供者的地址，后续的请求将不再通过注册中心。

首先，服务中心相对于 ESB 不再负责服务的日常沟通，因此相应的吞吐量也会有明显的下降。这种情况下实现服务注册中心的集群化就变得容易很多，这解决了 SOA 模式中最大的风险:单点的可靠性问题。避免了中心节点一旦出现问题，导致整个系统不可用的情况的发生。

微服务架构的第二个技术特点是服务的调用，通过 http 等轻量级通信协议进行直接通信，传统的 SOA 架构下，为了兼容各种不同的通讯协议，ESB 网关或者所有的流量进行协议转换权限验证等操作，并进行通信的转发。
同时，SOA 协议为了兼容各种复杂的通信场景，设计了相对复杂和冗长的通信协议，导致通信效率低下，而微服务架构下模块注册中心提前进行模块之间的协议协调和沟通，而在通信时得直接使用高效的轻量级协议进行直接通信，大大提高了分布式服务调用的效率，使得 ESB 的吞吐率不高的问题得以解决。

三、初步微服务化改造后引发的新问题

微服务架构，抛弃了 soa 架构中的 ESB 企业服务总线，通过轻量级的服务注册中心完成分布式服务，其核心思想是通过分散的微服务实例中的智能化组件代替集中式的服务控制调度节点，这意味以前有集中式中间件处理的如负载均衡，熔断降级，调用，跟踪的功能一致到微服务实例的智能化组件当中。
同时，随着微服务架构中服务节点数量的大幅度增长，服务实力自动化部署运维和生命周期管理也变成了开发者不得不考虑的实际问题。因此，综合这两方面的需求，在微服务架构的推进过程中出现了一个新的概念，也就是微服务治理。
微服务治理是指微服务架构中覆盖微服务整个生命周期，保障服务能高效健康运行的一系列功能和需求。
它涉及到开发，测试，运维等各个环节，包括负载均衡，容量降级，应用发布服务配置容量，规划弹性扩容调用，跟踪等大大小小几十个工具和框架。

简单说明这些服务的主要功能：负载均衡和熔断降级偏重于服务流量的调度和高并发场景下的系统健壮性，弹性扩容和发布回滚则偏重于服务实力的自动化创建部署，运行下限撤回销毁等生命周期管理操作。调用跟踪主要用于服务的日常运维监控。

微服务架构虽然看起来有很多优点，但是它也有一个问题是：一个微服务应用如果能够正常的运行，实际上它需要周边有一套相对完善的微服务治理框架，而微服务治理框架的逻辑和功能其实是比较复杂的。如果应用的开发者选择自己开发这套框架，他所付出的开发成本也是非常高的。
该种情况，2014 年作为知名视频播放网站，同时也是微服务技术的坚定拥护者奈飞公司将它们内部使用多年的一整套微服务解决方案贡献给了开源社区，并有配套公司封装成为了 spring 的产品。
在大型互联网公司和开源社区的共同推动下，搭建微服务治理框架的技术门槛迅速变低。

微服务架构，在企业应用开发中逐渐成为了主流架构，这和 SOA 时代由商业公司的中间件产品主导初步化服务架构。
在商业模式上产生了很大的不同在微服务架构的实践过程中逐渐形成了以服务注册中心，负载均衡，断路器配置中心微服往观这 5 部分组成的微服务核心治理框架。

图表中列出了常见微服务开发框架和五大核心组件的开源实践，其中粗体字部分为阿里巴巴贡献的开源产品。

关于各组件的主要功能做一个简单的介绍，其中微服务框架作为开发微服务中使用的代码框架，负责定义通信协议代码风格，并关联其他组件。
服务注册中心是核心组件中最重要的一个环节，负责微服务的注册和发现，以便服务之间可以互相调用，负载均衡负责在一个微服务的多个实例中找到最合适的服务提供者，断路器负责处理当某个微服务出现异常的情况，它会提供一种安全的失败机制，防止错误在调度链路上出现蔓延，配置中心为整个系统提供实时更新，集中管理的微服务配置服务而为微服务网关，负责微服务集群提供统一的对外接口，并进行身份验证，协议转换，安全检查的工作。

四、微服务架构内部组件的关系

在图中，红色的部分是由用户开发的微服务实例，他们基于微服务框架进行构建，并部署在不同的应用或服务器上，为外界提供服务。
右侧的箭头表示，当外部请求时进入到持续流程，首先外部请求会先通过微服务网关，由其进行安全检查，协议转换的工作在确认安全之后，微服务网关会将请求路由到具体的微服务集群中。这一步和传统的 eSB 协议转换相比，每一个微服务集群都使用不同的微服往观这就避免了 SOA 模式中过分依赖中心节点带来的吞吐压力和安全隐患。

第二步，外部请求会进入微服务集群中的服务注册中心，并由服务注册中心在注册过的服务中找到一个能处理相关访问请求的一个或多个微服务实例。然后再由负载均衡组件从能提供服务的实例中选择一个最适合的微服务实例，来响应对应的外部请求，这一步是微服务队伍中最核心的环节，负责实现从请求到服务实力之间的对应关系。

第三部外部请求会进入断路器组件，断路器组件提供一个安全的保险机制，如果微服务实例能正常地响应请求德断路器并不产生作用。如果在短时间内流入微服务实例的请求数量过大，超过微服务实例的处理能力，或者微服务一代处理请求时返回错误则抓住机会快速返回，并提供一个安全的错误处理方式，以避免外部请求长期冷战拖慢系统或一个错误引发雪崩式的错误蔓延。

最后一个功能组件是配置中心，它为运维人员提供了一个可以同时对成千上万部署在不同服务器的微服务实力进行动态配置。

五、微服务架构的优劣总结

对微服务的架构做一个技术总结，微服务架构相比于单体战斗有着巨大的优势，其优势主要体现在模块和模块之间的依赖不再像单凭一样中每个部门都可以选择更加适合开发与研制，更加符合其特点的周期。并单独进行设计，开发，测试和部署上线。每个服务的功能也比较单一，便于进行更加全面的白盒测试。

同时，由于服务中心和负载均衡组件存在，同一个维护模块，可以部署多个相同的实力，即使其中一个或几个出现问题，也不会导致该模块功能完全不可用。功能的健壮性单体运用拥有了非常大的提升。

相对于 SOA 角度，微服务上的优势主要有整体架构，采用去中心化设计及稳定性和最大并发数，并不会受到某个中心节点的限制。更符合现代互联网的企业应用特点，同时模块之间的通信协议简单和高效，开发人员学习门槛低，代码调试也更加容易。

但是微服务架构也有其存在的一些缺点，首先，微服务拆分的力道和服务的划分方式并没有一定之规，过出的划分密度会使微服务内部结构仍然复杂，无法避免单体用户确定，而过去的力度会使整个服务接口数量过多，模块内部逻辑暴露，网络通信号报道都很复杂。因此无论是过粗力度还是过细的力度都会对整体结构产生不利的影响，因此需要开发人员有一定的微服务开发经验才能找到比较适合业务场景的划分方式，其次，虽然开源社区中有了大量的微薄之力组建和框架，但是组合中的高性能高并发，高可用的微服务框架，仍然需要企业应用的开发和运维人员投入大量的精力进行维护，对一些规模小或研发实力强的公司人员成本和技术风险仍然很高。

最后就是微服务架构的分布式调用模式，决定了模块和模块之间的远程通信机制可靠性，远远低于单体应用架构，因此需要有更加完善的错误，是和异常处理机制，而分布式调研不能简单调用来清晰地展现登陆，如果没有合适的服务治理工具，对调用的电路进行跟踪和调试工作会变得异常复杂。
同时，由于微服务的远成调用特性，多个操作之间的同步梳理，复杂度也大大提高，需要专门的中间件进行支持。

六、下一代微服务框架 Server Mesh

微服务架构未来的发展趋势，在 2016 年左右的时候，推特公司推出了一套新的企业级软件框架,该架构的特点是相关服务的各个组件集中在一个单独的 Sidecar 组件中，微服务智能化主线运行在微服务所在的运行环境中，而整个集群所有环境中的 Sidecar 组成服务网络，微服务中的服务发现和微服务治理的流量管控调度都交给服务网络进行处理，微服务应用实例只需要通过和运行在本地的 Sidecar 就可以完成服务远程调用和请求，不再需要直接从远程服务器进行网络通讯，这种服务架构又有了进一步发展，其核心在于由 Sidecar 应用集群组成的服务网络，因此也被称为 Server Mesh 架构。
可以通过举例来比较 Server Mesh 架构、微服务架构和 SOA 之间的区别：在 SOA 架构中，所有人都需要去集中式购物中心才能进行购物，而微服务架构只需要在离家很近的分布式便利店中就可以方便采购自己所需要的东西，Server Mesh 架购得像外卖一样，只需要坐在家里就可以享受优质的商品和服务，2018 年，谷歌公司和 IBM 公司共同推出开发的新一代微服务框架，其社区发展也非常活跃，成为了事实上的 Server Mesh 行业标准，总体，Sidecar 应用集成了微服务治理框架中服务发现，负载均衡，断路器登录查看，微服务往观等核心组件功能，用户不再需要配置功能纷繁复杂的微服务治理框架，只需要单一平台即可完成恢复系统搭建，同时，Sidecar 模式使得微服务内部不再需要引用微服务核心组建，网络通信等功能模块。这样一方面简化了微服务应用的结构，另一方面也使得微服务开发不再受限制，可以从本机应用进行交互的开发权都可以开发微服务实例，同时 Mesh 架构在设计之初便考虑 Sidecar 和容器技术的结合以及整个服务网络，从开发 s 等容器编排框架的兼容性问题，但目前的功能完善度及第三方应用和业界的接受程度相比较于传统的经典微服务架构还是有一定差距，因此可以尝试，但是在正式开发企业用的时候，在现阶段还是需要谨慎地进行选择。