应用产品的微服务化之路拆分与重构

主要分享:
从正视msa开始
业务架构之服务拆分
技术架构之迭代重构
使用pdca环持续演化

展开查看详情

1.应用产品的微服务化之路 拆分与重构 徐进 恒生电子股份有限公司架构师

2.徐进 恒生电子股份有限公司架构师 来自于恒生电子股份有限公司的Java分布式架构资深专 家。 之前他和他的团队一直致力于恒生Java企业级应用开发 框架的研发和管理。此外,他还担任了上海清算所综合 业务系统、上海交易所注册审核系统、香港交易所商品 交易及结算系统等系统的首席架构师职责。

3.• 从正视MSA开始 • 业务架构之服务拆分 • 技术架构之迭代重构 • 使用PDCA环持续演化

4.回顾出生 微服务架构是一种架构模式,它提倡将单一应用程序划 分成一组小的服务,服务之间互相协调、互相配合,为用户提供最 终价值。每个服务运行在其独立的进程中,服务与服务间采用轻量 级的通信机制互相沟通(通常是基于HTTP的RESTful API)。每个 服务都围绕着具体业务进行构建,并且能够被独立的部署到生产环 境、类生产环境等。另外,应尽量避免统一的、集中式的服务管理 机制,对具体的一个服务而言,应根据业务上下文,选择合适的语 言、工具对其进行构建。 --摘自马丁.福勒先生的博客

5.膜拜大师 UML 极限编 微服务 程 企业应 马丁·福勒 用架构 重构 模式 敏捷联 分析模 盟 式

6.工程视角看待MSA 分工 • 独立进 程运行 微服务 核心问题域 协作 • 轻量级 通讯

7.• 从正视MSA开始 • 业务架构之服务拆分 • 技术架构之迭代重构 • 使用PDCA环持续演化

8.拆分之陷阱 微服务粒度仿佛雾里看花 数据一致性是一头拦路之虎 团队成员抱怨系统联调 拆分令我的产品成本上升

9.服务粒度 康威定律 1、5~9人的基础团队规模 微服务 2、团队成员的专业能力匹配 参考规 3、团队管理人员的能力匹配 模 4、保障团队安全的冗余能力 团队能力 成熟度

10.一致性方案 C:一致 根据场景选择分拆带来的 性 一致性解决方案 A:可用 P:分区 性 容错性

11.一致性方案 场景A:交易撮合 特点: 1、强时间序保证要求 2、并发处理下数据强一致要求 方案: • 撮合引擎内部不做微服务层切分, 优先确保数据一致, • 性能扩展采用节点冗余、内存交 易、查询分离等方式提升单个引擎 的处理能力和可靠性

12.一致性方案 场景B:证券经纪 特点: 1、时间序要求弱 2、并发处理下数据强一致要求 方案: • 交易引擎内的业务可以切分为交易 处理、资金管理、证券管理三个微 服务 • 使用TCC模式分布式事务管理一致 性 • 业务在交易过程中对资金与证券的 处理过程增加冻结中间状态

13.一致性方案 场景C:清结算 特点: 1、清算数据可采用异步方式进行抓取 2、无并发要求(针对对关联记录) 3、一致性通过异步对账保证 方案: • 清算引擎可拆分为资金、份额、分 控等不同服务 • 服务间取消RPC交互设计 • 清算引擎可按市场或产品等维度水 平扩展

14.链路监控 全链路跟踪 辅助问题的快速定位

15.链路监控 基于Dapper的分布式跟踪设计

16.链路监控 trace_id 区分调用链消息的唯一标识 span_id 跨度层级 depot_id 跨度里的层级 module_type (只有CS、SR、SS、CR四种) timestamp 时间戳(yyyy-MM-dd HH:mm:ss.SSS) name 服务名/节点名 ip IP地址 responseStatus 0表示成功,1表示失败 version 版本号,如:V2.3.1 spanType 链路类型,如:异步消息|RPC处理|数据库访问|缓存访问 serverName 服务标识 myPackage 自定义域 链路日志的规范定义

17.链路监控 { "info":[ "s1z2e34f5g67g8s1z2e34f5g67g8", "0.1", "r0", "CS", "2017-05-03 15:23:22.147", "msg_hs_msg#0", 链路日志的样例输出 "127.0.0.1", "0", "", "", "……"], "myPackage":{ "error_no":"-1", "error_info": "业务受理中,请稍后检查是否成功" } }

18.成本控制 关注的关键成本项

19.成本控制-双模架构 IT双模架构 接入 网关 第一元 l更加安全,更易把控,更加工业化 1.创新性业务,需求迭代频率以周或天为单位 创 2.服务的管理粒度细,每个微服务对应一个独立的业务模块 中台 新 3.能够通过灵活的服务组装开发新的业务服务 微服务 服 双模 4.服务之间的实时并发与一致性要求较低 务 架构 系统间 第二元 网关 l更加创新,更加快捷,更注重协作 1.需求稳定,变更和迭代的频率以月或年为单位 稳 后台 定 2. 服务服务的管理粒度粗,一般以子系统为最小粒度 服 3.实时并发与一致性要求较高的业务 务

20.成本控制-架构封装 运行环境 让业务开发专注业务逻辑实现 协议代理 架构层 • 轻量级通信之轻 服务规范 • 系统容量估算不要因分布式弹性而忽 略 业务实现 与调用 业务层

21.成本控制-架构封装 服务元数据和组件封装屏蔽了应用开发对PAAS层的依赖

22.成本控制-工具辅助 开发工具 • 统一元数据管理 • 解决并行开发冲突 • 固化编码经验 • 降低开发引入的缺陷数

23.成本控制-工具辅助 运维工具 • 发布物统一管理 • 自动化应用部署 • 系统监控集成 • 日志与链路跟踪

24.成本控制-DEVOPS支持 … … 载 镜像下 界面操作 客服交付 控制台 署 一键部

25.成本控制-DEVOPS支持 使用脚手架工程 屏蔽交付细节

26.• 从正视MSA开始 • 业务架构之服务拆分 • 技术架构之迭代重构 • 使用PDCA环持续演化

27.重构之陷阱 重构带来的系统兼容问题 重构的成本难以控制 没有观测和度量的重构

28.兼容性-管理系统关键信息 • 系统对外交互信息 接口:系统功能兼容 扩展点:二次开发兼容 应用配置:部署环境兼容 • 系统内部元信息 环境上下文:上下文是系统内达成共识的一致性环境数据描述 运行生命周期:运行生命周期是系统活动过程的阶段定义 服务契约:它除了功能接口描述外,还包含了服务质量描述 (如熔断阀值、Apdex T、路由策略等)

29.控制成本-依赖自动化 • 开发框架提供自动化模型转换 使用模板语言进行部分重构类的生成 利用脚手架工程完成配置拆分 • 自动化测试 使用Maven+FindBugs+TestNG实现自动化静态检查和测试 • 自动化发布部署 使用公司统一的监控运维工具发布和部署应用,实现灰度升级