内容总结自《微服务架构设计模式》


逃离单体地狱

  • 一、单体架构
  • 1、好处
  • 2、弊端
  • 二、微服务架构
  • 1、定义
  • 2、好处
  • 3、弊端
  • 三、模式的概念
  • 1、定义
  • 2、构成
  • 3、引申微服务


一、单体架构

1、好处

  1. 易于对应用程序进行大规模的更改：可以更改代码和数据库模式，然后构建和部署。
  2. 测试相对简单直观：开发者只需要写几个端到端的测试，启动应用程序，调用RESTAPI，然后使用Selenium这样的工具测试用户界面。
  3. 部署简单明了：开发者唯一需要做的，就是把WAR文件复制到安装了Tomcat的服务器上。
  4. 横向扩展不费吹灰之力：FTGO可以运行多个实例，由一个负载均衡器进行调度。


2、弊端

  1. 过度复杂性会吓退开发者
  2. 开发速度缓慢
  3. 代码提交到实际部署的周期很长，而且容易出问题
  4. 难以扩展
  5. 交付可靠的单体应用是一项挑战
  6. 需要长期依赖某一个可能已经过时的技术栈


二、微服务架构

1、定义

microservice用来指代微服务这类架构设计风格，而构成微服务架构的是每一个具体的实例，是service（服务）。所以我们应该说，“这个系统采用了微服务架构设计，由若干个服务构成”。

这里借助了Martin Abbott和Michael Fisher的名著《The Art of Scalability》 的启发，该书中描述了一个三维可扩展模型：“扩展立方体”，这个模型描述了一个应用程序的三个维度：

  • X轴扩展：在多个实例之间实现请求的负载均衡
  • Z轴扩展：根据请求的属性进行路由请求（并未网关转发，而是根据请求参数值，定点打到某台固定的机器上）
  • Y轴扩展：根据功能把应用拆分为服务

服务本质上是一个麻雀虽小但五脏俱全的应用程序，它实现了一组相关的功能，例如订单管理、客户管理等。服务可以在需要的时候借助X轴或Z轴方式进行扩展。例如，订单服务可以被部署为一组负载均衡的服务实例。

我对微服务架构的概括性定义是：把应用程序功能性分解为一组服务的架构风格。请注意这个定义中并没有包含任何与规模有关的内容。重要的是，每一个服务都是由一组专注的、内聚的功能职责组成。微服务作为模块化的一种形式，每个服务都有自己的数据库。



2、好处

  1. 使大型的复杂应用程序可以持续交付和持续部署。
  2. 每个服务都相对较小并容易维护。
  3. 服务可以独立部署。
  4. 服务可以独立扩展。
  5. 微服务架构可以实现团队的自治。
  6. 更容易实验和采纳新的技术。
  7. 更好的容错性。


3、弊端

  1. 服务的拆分和定义是一项挑战
  2. 分布式系统带来的各种复杂性，使开发、测试和部署变得更加困难
  3. 当部署跨域多个服务的功能时需要谨慎地协调更多开发团队
  4. 开发者需要思考到底应该在应用的什么阶段使用微服务架构


三、模式的概念

1、定义

模式是一个客观的工具，在通过模式的形态描述一项技术时，必须包括它的弊端。模式是针对特定上下文中发生的问题的可重用的解决方案，是Christopher Alexander创造的，他是一位显示世界中的建筑架构师。（类比设计模式理解）

2、构成

模式的价值远远超出了要求架构师考虑问题的背景，它迫使架构师认真描述解决方案的其他关键但经常忽视的方面（类比开发前的技术方案）。常见的模式结构包含三个重要部分：

  1. 需求：描述了必须解决的问题和围绕这个问题的特定上下文环境
  2. 结果上下文：采用模式后可能带来的后果
  1. 好处：好处和解决了什么需求
  2. 弊端：弊端和没有解决哪些需求
  3. 问题：使用模式后引入了什么新的问题
  1. 相关模式：这个模式与其他模式之间的关系
  1. 前导：前导模式是催生这个模式的需求的模式，例如微服务架构模式是除单体架构模式以外整个模式语言中所有模式的前导模式
  2. 后续：用来解决当前模式引入的新问题的模式
  3. 替代：当前模式的替代模式，提供了领导的解决方案
  4. 泛化：针对一个问题的一般性解决方案
  5. 特化：针对特定模式的具体解决方案

此外，你可以把解决类似问题的模式组成一组模式。对相关模式的明确描述为如何有效解决特定问题提供了有价值的指导。



3、引申微服务

《微服务架构设计模式》第一章 逃离单体地狱_数据库

微服务中的这些模式被分为三组：基础设施相关模式组、应用基础设施相关模式组、应用相关模式组。这些模式根据所解决问题的不同可以进一步的分组，主要分为：

  1. 服务拆分相关模式
  • 根据业务能力分解
  • 根据DDD域划分
  1. 通信相关模式
  • 通信风格
  • 服务发现
  • 可靠性
  • 事务性消息
  • 外部API
  1. 实现事务管理的数据一致性相关模式
  • 每个服务数据库独立配置，传统事务不适用
  1. 在微服务架构中查询数据的相关模式
  • LEFT JOIN变为多个API接口结果聚合
  1. 服务部署的相关模式
  • WAR上传服务器变为自动化部署平台
  1. 可观测性的相关模式
  • 健康检查API
  • 日志聚合
  • 分布式追踪
  • 异常跟踪
  • 应用指标
  • 审计日志
  1. 实现服务自动化测试的相关模式
  • 消费端驱动的契约测试：验证服务满足客户端所期望的功能
  • 消费端契约测试：验证服务的客户端可以正常与服务通信
  • 服务组件测试：在隔离的环境中测试服务
  1. 解决基础设施和边界问题的相关模式
  • 需要一个微服务基底，否则每开一个新服务，都需要重复处理可观测性模式、服务发现模式以及实现外部化配置模式
  1. 安全相关的模式
  • 用户身份验证