基于微服务架构改造单体 架构的实践总结

李林锋 微博、微信：Nettying

个人简介

李林锋，2007年毕业于东北大学，2008年加入华为， 从事电信软件的架构设计和开发。8年Java NIO通信 框架、网关平台和中间件设计和开发经验，精通Java NIO、Java多线程编程和分布式服务框架等，《分布 式服务框架原理与实践》作者，目前从事云平台相关 的架构设计和开发。

公众号：Netty之家，分享Netty、服务化相关的各种案例 和实践

目录

1 传统单体架构的弊端 2 服务化架构的演进历史 3 微服务架构的实施 4 最佳实践

统单体架构的弊端



研发成本高：

Ø 代码重复率高 Ø 需求变更困难 Ø无法满足新业务快速上线 和敏捷交付

传统单体架构的弊端

运维效率低：

Ø 测试、部署成本高：业务运行在一个进程中，因此系统中任何程序的改变，都需要对整个系统

重新测试并部署

Ø 可伸缩性差：水平扩展只能基于整个系统进行扩展，无法针对某一个功能模块按需扩展 Ø 可靠性差：某个应用BUG，例如死循环、OOM等，会导致整个进程宕机，影响其它合设的应用 Ø 代码维护成本高：本地代码在不断的迭代和变更，最后形成了一个个垂直的功能孤岛，只有原

来的开发者才理解接口调用关系和功能需求，新加入人员或者团队其它人员很难理解和维护这些代码

Ø 依赖关系无法有效管理：服务间依赖关系变得错踪复杂，甚至分不清哪个应用要在哪个应用

之前启动，架构师都不能完整的描述应用的架构关系

解决对策

服务化： Ø 拆分：对应用进行水平和垂直拆分 Ø 解耦：通过服务化和订阅、发布机制对应用调用关系解耦，支持服务的自动注册和发现 Ø 透明：通过服务注册中心管理服务的发布和消费、调用关系 Ø 独立：服务可以独立打包、发布、部署、启停、扩容和升级，核心服务独立集群部署 Ø 分层：梳理和抽取核心应用、公共应用，作为独立的服务下沉到核心和公共能力层，逐渐形成稳

定的服务中心，使前端应用能更快速的响应多变的市场需求

服务化架构的演进历史

1、MVC：解决前后端、界面、控制逻辑和业务逻辑分层问题 2、RPC：远程过程调用，本质就是分布式协作和系统间的解耦 3、SOA：服务化架构，企业级资产重用和异构系统间的集成对接 4、微服务化架构：敏捷交付、互联网、容器化发展的产物

微服务架构

定义：微服务（MSA）是一种架构风格，旨在通过将功能分解到各个离散的服务中

以实现对解决方案的解耦。

特征：

Ø 小，且只干一件事情 Ø 独立部署和生命周期管理 Ø 异构性 Ø 轻量级通信，RPC或者Restful

微服务架构的实施



微服务拆分原则：围绕业务功能进行垂直和水平拆分。大小粒度是难点，也是

团队争论的焦点。



不好的实践：

Ø 以代码量作为衡量标准，例如500 行以内

Ø 拆分的粒度越小越好



建议的原则：

Ø 功能完整性、职责单一性 Ø 粒度适中，团队可接受 Ø 迭代演进，非一蹴而就 Ø API的版本兼容性优先考虑

微服务架构的实施



微服务开发原则：接口先行，语言中立，服务提供者和消费者解耦，并行

开发，提升产能。



不好的实践：

Ø 服务提供者专注于内部实现，而不 是优先提供契约化的接口

Ø 担心接口变更，迟迟不提供接口契 约，导致消费者无法并行开发



建议的原则：

Ø 接口优先 Ø 允许契约的变更，但项目组需 就接口的兼容性做约束 Ø 契约驱动测试，实现服务提供 者和消费者解耦 ØIDL，代码骨架自动生成

微服务架构的实施



微服务测试原则：单元测试，契约测试（接口测试），行为测试，集成测试。



消费者 模 提供者



拟



服务 桩



客户



端端



Mock



Mock



框架



框架



分布式服务框架



微服务框架提供服务端和客户端Mock框架



消费者1 消费者2 消费者...N



接口 契约

1、接口定义 2、测试用例 3、码流 4、错误码...



提 供 者

微服务架构的实施



微服务部署原则：独立部署和生命周期管理、基础设施自动化。



启动 停止 升级 回滚 下线



选择



微服务名 订单管理 用户管理 鉴权认证



版本号 1.0.1 1.0.1 1.0.6



分组信息 无锡 南京 镇江



实现关键：微服务独立打包，物理交付件

独立，例如jar包



CI 每日构建 部署环境

自动化部署

测试环境 灰度环境 生产环境

核心技术：

1、持续交付流水线 2、Docker或PaaS平台

微服务架构的实施



微微服务运行容器：Docker、PaaS平台（VM）



MS1



MS2



MS3



物理机

使用Docker部署微服务的优点总结：

1. 一致的环境：线上线下环境一致 2. 避免对特定云基础设施提供商的依赖 3. 降低运维团队负担 4. 高性能：接近裸机的性能 5. 多租户



微服务云化：

1. 云的弹性和敏捷 2. 云的动态性和资源隔离 3. Dev&Ops

微服务架构的实施



微服务治理原则：线上治理、实时动态生效



服务治理展示层



服务治理Portal



服务治理元数据 服务治理SDK



服务治理接口和客户 端



服务注册中心集群 Governance服务层



服务治理服务集群



微服务治理策略：

1. 流量控制：动态、静态流控 2. 服务降级 3. 超时控制 4. 优先级调度 5. 流量迁移 6. 调用链跟踪和分析 7. 服务路由 8. 服务上线审批、下线通知 9. SLA策略控制...

微服务最佳实践

服务路由：本地短路策略



消费者 优先 提供者



JVM 其次



消费者



提供者



JVM 服务器/VM



最后



提供者

JVM

提供者 JVM 服务器/VM



关键技术点：

Ø 优先调用本JVM内部服务提供者、 Ø 其次是相同主机或者VM的、 Ø 最后是跨网络调用

微服务最佳实践



服务调用方式：同步调用、异步调用、并行调用



同步方式：



并行方式：



Network



异步方式：

1、Invoke()

Sevice Thread 4、获取Future



IO Thread



2、write request 7、read response



5、返回Future 3、返回Future对象 8、设置结果，唤醒阻塞的用户线程



6、主动get结果，同步阻塞



Future

微服务最佳实践

微服务故障隔离：线程级、进程级、容器级、VM级、物理机...

关键技术点：

1. 支持服务部署到不同线程/ 线程池中 2. 核心服务和非核心服务隔离部署

微服务最佳实践



事务一致性：大部分是最终一致性、极少部分需要强一致性



本地事务：



分布式事务：



策略：

1. 最终一致性， 消息中间件 2. 强一致性，TCC

微服务最佳实践



时延问题：非阻塞I/O、二进制、长链接、码流压缩



本地接口调用



接口1



接口2



JVM



服务化



消费者

接口1

JVM



说明：在服务化之前，业务通常都是本地API调

用，本地方法调用性能损耗较小。服务化之后， 服务提供者和消费者之间采用远程网络通信，增 加了额外的性能损耗



网络

提供者

接口2

JVM



通信性能三要素：

ü I/O模型 ü 线程调度模型 ü 序列化方式

微服务最佳实践

微服务接口兼容性：技术保障、管理协同

1.制定并严格执行《微服务前向兼容性规范》，避免发生不兼容修改或者 私自修改不通知周边的情况 2、接口兼容性技术保障：例如Thrift的IDL，支持新增、修改和删除字段，字段 定义位置无关性，码流支持乱序等 3、持续交付流水线的每日构建和契约化驱动测试，能够快速识别和发现不兼容

QA

谢谢大家！