遗留系统到微服务架构

1.微服务定义：
微服务架构是一种架构风格，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。
每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通（如基于 HTTP 协议的RESTful API）。
每个服务都围绕着具体业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。
2.一个典型的微服务部署结构
必须有一个devops平台提供包括协作平台（看板系统、需求空间）、代码仓库、服务监控平台、发布单元管理、代码检视、运营数据监控、流水线（构建、测试、发布）等功能，承担整个研发生命周期
前端不同入口，走一个独立的微服务网关，流量进入具体的微服务。
Paas层提供两部分能力，一个是云数据库、消息中间件、搜索引擎等基础设施，以及服务注册、配置中心、日志服务等服务网格化的服务单元。
IaaS提供计算、网络、存储、虚拟机、容器平台等基础设施
3.分析现有系统：
根据不同系统情况以及项目成员对系统熟悉成都，按需对系统做分析，以明确划分微服务时的边界问题。包括以下六方面：
架构分析、组件依赖分析、部署分析、系统规模分析、系统集成分析、业务分析
可以使用的工具有三种：
①C4模型工具：是一种可视化现有架构的技术，将系统抽象为四个层次，在每个层次刻意忽略一些细节才能表达好当前层次的抽象信息。C4模型将系统从整体到局部、从概略到详细的展现出来。四个层次分别是系统级别、容器（发布单元）级别、组件级别、代码级别，它们有各自的工具，分别是：
系统上下文图：系统与用户和其他系统间的关系
容器图：绘制组成该系统的容器（应用程序、数据存储、微服务）
组件图：绘制组件映射到代码库中的真实抽象
代码图：按需绘制个别组件，描述其实现方式
②领域模型分析：用DDD领域建模方法产生领域模型，来源为代码模型、业务知识、数据库模型
③数据库表依赖分析：分析不同模块对数据库表的依赖关系。可以用开源工具、读代码等办法
4.微服务划分颗粒度：
视具体问题具体分析：
• 通常情况下，后端微服务的数量不超过开发人员的数量（视业务场景不同会有变化，更新频率极低的服务/产品，可以暂不计入） 。
• 康威定律。微服务与开发组对齐。
• 两个比萨团队原则 —— 开发组的人员数量维护在 3 ~ 12 人。一个微服务只由一个开发组维护。
• 高内聚，低耦合。单个服务与其它服务依赖少。如：两个服务存在相互调用，耦合度相对较高，可以考虑合为一个服务。
• 收益大于开销。创建服务的开销是否超过了独立成服务的好处。
• 你不一定需要微服务。考虑采用 DDD （领域驱动设计）分层架构来划分，以方便未来拆分为微服务。
5.微服务改造优先级确定
根据实际情况评分，从三个维度量化改造工作
业务维度：评分越高，表示越需要微服务化来更快更好的支持业务需求，改造意义高
管理维度：评分越高，表示管理角度难度越大
技术维度：评分越高，表示技术风险挑战高，微服务化接触的空间越广越深
业务维度包括：业务价值、需求变化频率、业务复杂度、业务访问量、系统痛点
管理维度包括：组织结构不匹配度、预算投入、改造意愿
技术维度包括：系统耦合度、技术复杂度、数据迁移难度
6.改造准备：
自动化测试保证功能不被破坏，主要需增加api和组件级别自动化测试，如果ui不变增加ui测试
7.前端优先演进策略：
增加API网关作为防腐层接入多个前端入口。再增加BFF（前端专属后端）和拆分微服务。BFF指的是为每种用户触点建立单独后端，对每个后端行为和性能进行精心调整，提供最匹配的环境，隔离其他前端入口的环境。这种专属后端会更小、更简单、更快。
8.后端优先演进策略：
先增加API网关和拆分微服务，再增加多个前端入口以及BFF层。
9.后端演进策略：
绞杀者模式：使用新的服务逐渐替换遗留系统的特定功能部件来逐步迁移。由于替换遗留系统的功能，新系统最终将替代旧系统的所有功能，绞杀并允许停用旧系统。这种模式有助于最大限度地减少迁移的风险，并随着时间推移扩大开发工作。通过安全地将用户路由到微服务，以任何喜欢的速度向新服务添加功能。
修缮模式：在既有系统资产的基础上，通过剥离新业务和功能，逐步“释放”现有系统耦合度，解决遗留系统质量不稳定和 Bug 多的问题。实现传统 IT 性能提升，面对传统的 IT 业务更加稳定灵活，降低维护成本。修缮模式适用于需求变更频率不高的存量系统。
影子流量策略：其实就是灰度发布。
10.遗留系统改造全景