华为云DevOps系列之 —— 持续部署与发布（二）微服务架构与微服务化应用

应用架构向微服务架构演进

第一代：单体架构

• 紧耦合
• 系统复杂、错综交互，牵一发而动全身
• 重复制造各种轮子：OS、DB、Middleware
• 完全封闭的架构

第二代：SOA 架构

• 松耦合
• 在大型、超大型企业中仍然流行
• 通常通过 ES8 进行系统集成
• 大团队：100~200人
• TTM(Time To Marketing)、一年、半年、月
• 集中式、计划内停机扩容

第三代：微服务架构

• 解耦
• 互联网公司、中小企业、初创公司
• 小团队：2 Pizza Team
• TTM：按天、周进行升级发布
• DevOps：CI，CD，全自动化
• 可扩展性：自动弹性伸缩
• 高可用：升级、扩容不中断业务
• 高效：服务器加容器可以实现秒级的弹性
• 更经济：按需弹性

微服务是当前和未来主流架构，带来的核心价值是能 缩短业务上线周期 和 保障业务运行高可靠

微服务的特征

微服务特征

• 小
  • Small services
  • 粒度小，且专注一件事情
• 独
  • Own process
  • 单独的进程
• 轻
  • Lightweight mechanisms
  • 轻量级通信机制，通常是 HTTP/REST 接口
• 松
  • Independently deployable
  • 松耦合、可独立部署

如何界定微服务

• 多小算小？
  • 代码行数？重写时间？跟语言、技能相关？都不适合
  • 亚马逊认为：由 2-Pizza 团队端到端负责1个或者1组服务，大小是适合的
• 区别于传统单体应用
  • 传统单体应用各个模块、组件或动态是集成在一个 大进程 中运行的
• 区别于传统 SOA 架构
  • SOA 架构是基于总线 ESB、Centralized Governance 集中管控的架构
• 每个微服务可独立编译（无二进制接口依赖），独立部署（无部署顺序依赖），独立运行（无启动顺序依赖）

微服务设计 - DDD 领域驱动模型

• 有时一个领域往往太复杂，涉及到的领域概念、业务规则、交付流程太多，导致我们没办法直接针对这个大的领域进行领域建模。所以，我们需要将领域进行拆分，本质上就是把大问题拆分为小问题
  • 子域的边界
  • 核心子域与非核心子域
  • 公共支撑子域
  • 子域之间的关系

以一个 电商系统 来举例

• 会员中心：负责用户账号登录、用户信息的管理
• 商品中心：负责商品的展示、导航、维护
• 订单中心：负责订单的生成和生命周期管理
  • 历史完成订单
  • 待支付订单
  • 取消订单
• 交易中心：负责交易相关的业务
• 库存中心：负责维护商品的库存
• 促销中心：负责各种促销活动的支持

本质上作为一种架构方法的 DDD 和作为一种架构风格的 Microservices 都是为着 追求高响应力目标 从 业务视角 去分离复杂度的手段

微服务架构支撑持续部署

• 传统应用部署：集成 -> 测试 -> 发布，发现了高优先级 bug，又有经历一套这样的流程。随着应用程序的复杂和功能的添加，整体应用程序的发布过程会变得更加脆弱且可能中断
• 微服务：通过分解模块，由每一个小团队负责一小块独立解耦的业务的开发和发布
• 如下图，传统应用程序，需要等到合并、测试完成后才能进行部署；而微服务中 “A” 可以随时发布更新，无需等待 “B‘
  

微服务底座（CHASSIS）

• 业务和模块的分解可能会带来很多的挑战。在以前单体应用中，都是进程内的调用，不要考虑服务发现、服务调用、服务负载均衡，现在我们把一个大业务分解成了众多小的微服务之后，这些问题就都要考虑，这也就是新增的成本和门槛
• 其次，同样的拆分成多个微服务从理论上来说意味着他的故障点是增加的，如何在运行态管理或者是治理这些微服务是新的问题，靠人工实现是不太可能的，分布式系统里面的任务太复杂了
• 另外，以前是在一个应用中找 bug，现在是在 N 个服务的 N 个实例中去找 bug，靠人工实现的话，比如定位问题，是非常困难的。
• 类似于日志框架（log4j/logback）、健康检查、metrics、分布式追踪，这些在所有服务中都要解决的问题，叫做横切面问题（cross-cutting concerns）。微服务底座（微服务框架）就是用来帮助我们解决这些问题的
• 使用框架时，只需要使用注解/配置简单的方式就可以解决上述提到的问题
• 常见的微服务底座：SpringCloud、Dubbo、ServiceComb

• 另外一种解决横切面的方法是使用 Service Mesh 服务网格。原理是每一个微服务都会额外的部署一个 反向代理组件，由这个组件提供解决问题的能力，也就是说所有出站、入站的流量都会通过该组件进行处理和转发，这个组件就叫做 Sidecar
  

Spring Cloud

• SpringCloud 是目前完整的微服务解决框架，功能非常强大
  • Zuul 是 Netflix 的一个基于 JVM 路由和服务端的 负载均衡器。它的作用就是 服务转发，接收并转发所有内外部的客户端调用。使用 Zuul 可以作为资源的统一访问入口，同时也可以在网关做一些权限校验等类似的功能
  • Eureka 是 Netflix 的 服务注册和发现组件，将所有的可以提供的服务都注册到它这里来管理，其它各调用者需要的时候去注册中心获取，然后再进行调用
  • Config 为服务端和客户端提供了 分布式系统的外部化配置 支持。它包含了 Client 和 Server 两个部分，Server 提供配置文件的存储、以接口的形式将配置文件的内容提供出去，Client 通过接口获取数据、并依据此数据初始化自己的应用
  • Zipkin 是 分布式实时数据追踪系统，其主要功能是聚集来自各个异构系统的实时监控数据，Sleuth 为服务之间调用提供链路追踪
  • Feign 是一个声明式的 Web Service 客户端，它的目的就是 让Web Service 调用更加简单。它整合了 Ribbon 和 Hystrix，从而让我们不再需要显式地使用这两个组件

ServiceComb

• 包括应用框架代码生成，服务注册发现、服务配置管理、服务监控、服务调用追踪、多通信协议支持等功能
• 具备服务化契约增强、事件驱动等优势特性，提供分布式事务追踪能力
• 采用开放架构设计理念，兼容多种业界流行微服务框架，开发者可根据自身业务需求定制业务插件
• 服务契约的作用贯穿 ServiceComb 的三个模型，而不是简单地作为接口文档。服务契约将三个模型解耦，这使得运行模型中的同一套微服务治理逻辑既可以用于不同的开发风格代码，也可以用于不同的通信方式，让框架的功能扩展能力更好。同时接口契约规范了 provider和 consumer 双方的交互行为，让开发与测试之间、不同微服务的开发之间的沟通协作效率更高
• CSEJavaSDK 作为一个带服务契约的 REST 开发框架，在使用上不会像传统的 Servlet 开发方式那么随心所欲，但随着系统规模扩大、复杂度提升，服务契约带来的好处将会明显大于其在开发方式上的限制

华为微服务解决方案 ServiceStage 平台

• ServiceStage 是一个应用托管和微服务管理平台，可以帮助企业简化部署、监控、运维和治理等应用生命周期管理工作
  

最后，欢迎大家关注我的个人微信公众号 『小小猿若尘』，获取更多IT技术、干货知识、热点资讯。同时，我在公众号中分享了精心整理的一些视频资料（包括 Python全栈教程、AI教程、前端、数据库等），大家回复相应关键词即可获取网盘视频链接，感谢大家的关注😊