“架”驭全局、“构”筑未来—微服务架构转型
引言
一、为什么要微服务转型
二、什么是微服务
1、概念定义
Martin Flower：
In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery.
微服务是一种架构风格，提倡将应用分解成一系列足够小的服务，每个服务专注于单一的业务功能，在独立的进程中运行，服务之间边界清晰，采用轻量级通讯机制相互沟通、配合来实现完整的应用，满足业务和用户的需求。
2、微服务的特征
3、微服务的优势与挑战
三、微服务转型策略方案
1、总体目标
通过搭建和完善微服务基础支撑环境，快速推进微服务在特色场景需求中的应用，实现对业务需求的快速响应和支持，提升微服务架构治理水平，促进IT研发能力升级。
2、微服务落地关键技术点
3、微服务总体架构
4、构建基础支撑环境策略
以快速支持微服务应用转型验证和试点为目标，从构建核心支撑环境开始，逐步完善微服务基础支撑能力
5、微服务架构的应用转型策略
微服务有其适用的应用对象，不是所有应用都适合适用微服务构建，在开始一个应用的微服务改造前，我们通常需要对其进行针对性的评估分析。
可以从微服务总获益较大的系统：
- 渠道交互类系统：指以与用户交互为主要目的系统，如各类移动应用，互联网应用，特色社会化平台应用等。
- 记录型系统：指对所关注领域的信息以增删改查作为应用核心的系统，如CRM，ERP、OA等。
6、应用系统转型评估：建立应用转型实施评估模型，以充分评估实施过程中的技术风险和投入
在对应用进行微服务转型评估时，以业务核心价值需求为主要依据，并充分评估实施过程中的技术风险、团队能力风险，寻找突破口，并推动基础设施建设的升级。
7、微服务应用拆分方法
基于领域驱动设计（DDD）+主数据驱动设计（MDD）+现有系统建设经验相结合的方法，对现有应进行微服务拆分。
8、现有应用的微服务转型模式
1）、模式一：转型业务价值高，转型紧迫性要求高的业务需求，采用微服务新建应用
如果新需求与现有系统耦合性不高，可采用微服务技术框架建立独立的子系统。
场景：
- 需求变化快，有快速上线，快速迭代要求的创新功能
- 业务交易量大，高并发的热点功能
- 访问量很大，访问频繁的公共功能
2）、模式二：有架构转型需求的现有系统，针对痛点部分采用微服务架构重构
转型目标是提升系统扩展能力，提高系统稳定性，敏捷交付。
场景：
- 业务存在热点与边缘功能不分，横向扩展资源浪费或存在困难的，拆分出热点功能
- 功能耦合度高，导致团队规模大，系统维护和版本升级困难的，对系统进行组件化改造，进行必要的应用拆分
3）、模式三：转型价值和紧迫性要求不高的系统，保留并通过融合架构与微服务交互
- 对于老旧又缺乏维护的系统，无法重构为微服务架构的系统，SOA资产重用化应该是更佳的解决方案。
- 原有应用无法改变数据存储方式。
9、优化开发流程，实现敏捷转型
微服务的特点使得它对于对敏捷开发适应强。通过优化开发流程，借助DevOps一体化工具，实现微服务敏捷开发、持续集成与持续交付的落地。
10、实现微服务自动化运营
微服务使得运维的复杂度大大提升，如何保证上万的服务、上千的容器正常运行？使用传统方式是无法保证的，如果不建立对应的平台、工具、方式、方法去管理微服务应用，将会严重影响微服务的落地。
11、提升微服务治理效率
12、组织形式转型：建立领域细分的、跨职能的研发团队
“特性团队”，即是一个领域细分的跨职能的团队。每个团队包括需求分析、方案设计、开发测试等多个角色，专注于领域逻辑，实现该领域特性的完整的端对端开发。
“组件团队”解决那些公共型的基础型的问题。该团队需具有有专门知识或能够应对具有一定技术复杂度，有相当专业门槛要求的专有功能。
典型的由多个特性团队组成的大型开发团队组织结构典型的由多个特性团队组成的大型开发团队组织结构
特性团队的组织有利于团队的沟通。每个团队分别做各自限界上下文的工作，由于工作的弱相关性带来自然而然的团队隔离。
如果同一个限界上下文的工作交给了两个不同的团队分工完成，为了合力解决问题，就必然需要这两个团队进行密切的沟通。