1、?CONTENTS01引言02可视化的认识遗留系统03可视化的划分遗留系统04可视化的拆解遗留系统引言遗留系统、微服务架构任何人类的设计都会腐化软件当然也不例外拆成微服务微服务架构的九大特征通过服务进行组件化围绕业务能力组织做产品而不是做项目智能端点与傻瓜管道去中心化地治理技术去中心化地管理数据基础设施自动化容错设计演进式设计可视化能帮我们什么掌握系统业务明确系统边界小步改造系统可视化的认识遗留系统C4模型、用户画像、用户旅程C4模型系统架构可视化国家级省级道路级市级C4模型系统架构可视化系统上 下文图容器图代码图组件图已可视化用户画像和旅程系统功能用户可视化用户画像用户旅程已可视化突出用户信

2、息，诉求和价值体现还原业务场景可视化的划分遗留系统领域驱动设计、事件风暴工作坊、服务画布好的设计低耦合如果做到了服务之间的松耦合，那么修改一个服务就不需要修改另一个服务。一个松耦合的服务应该尽可能少地知道与之协作的那些服务的信息。高内聚就是把相关的行为聚集在一起，把不相关的行为放在别处。如果你要修改某个服务的行为，最好只在一处修改。领域驱动设计领域驱动设计是一种处理高度复杂域的设计思想，试图分离技术实现的复杂性,围绕业务概念构建领域模型来控制业务的复杂性，以解决软件难以理解，难以演化等问题。团队应用它可以成功地开发复杂业务软件系统，使系统在增大时仍然保持敏捷。事件风暴工作坊-Event Sto

3、rming是一种领域建模的实践，是一种快速探索复杂业务领域的方法：-最初由Alberto Brandolini开发，经过DDD社区和TW的很多团队实践验证后，于2015年11月进入ThoughtWorks技术雷达Powerful：可以让实践者在数小时内理解复杂的业务模型Engaging：把带着问题的人和拥有答案的人共聚一堂构建模型Efficient：跟DDD的实现模型高度一致，并能快速发现Aggregate和 Bounded ContextEasy：标记都很简单，没有复杂的UMLFun简介正确的人：业务人员，领域专家，技术人员，架构师，测试人员等关键角色都要参与其中开放空间：有足够的空间可以将

4、事件流可视化，让人们可以交互讨论彩色即时贴：至少三种颜色活动准备寻找领域事件事件风暴命令风暴寻找聚合划分限界上下文什么是事件？为什么用事件？如何进行事件风暴？事件：领域专家关心的，在业务上真实发生的事例1:客户订单已提交例2:对账已完成，每月末夜间触发1.确定要进行事件风暴的业务场景，场景需要单一而且清晰；2.用“XXX已XXX”的格式在橙色便利贴上写下事件，工作坊参与者需要对事件定义达成一致；3.根据时间顺序把事件便利贴贴到白板上；4.如果一个事件有同步发生的其它事件，把其它事件放在事件下方；5.如果发现了业务中的问题点，用红色便利贴记录为什么是一个问题；6.以上步骤完成以后，再从最后一个事

5、件开始来反向验证事件的完整性（即：走查前后事件的关联关系，防止有些事件被遗漏）。通过事件的方式对过去发生的事情进行溯源，因为过去所发生的对业务有意义的信息都会通过某种形式保存下来。事件风暴能够让领域专家和工作坊参与者一起明确在业务上究竟是什么领域模型发生了什么改变，最终的软件系统需要关注业务过程中发生的业务数据的变化。事件风暴示例订单 已创建订单 已支付商城库存 已扣减仓库库存 已占用商品 已创建订单 已撤销商城库存 已增加出库单已 生成出库单已 发货投诉单 已创建投诉单已 处理商城库存 已编辑商品 已发布商品销售 价格已编辑订单 已发货补货申请 单已创建补货申请 单已审批入库单 已创建入库单

6、 已入库订单 已签收订单已 确认收货仓库库存 已扣减仓库库存 已增加商品已 编辑退货单已 创建退货单已 审核订单已 退货入库单 已创建入库单 已入库仓库库存 已增加寻找命令事件风暴命令风暴寻找聚合什么是命令？为什么用命令？如何进行命令风暴？命令：什么活动产生了事件 例1:提交客户订单例2:启动夜间对账事件是业务上的输出，命令是业务上的输入。命令以及相应角色可以明确最终软件系统会有哪些功能给外界使用。命令和事件将会在后续的环节中指导API的设计。1.将命令写在蓝色即时贴上，可以是 用户从UI界面进行的操作 外部系统触发 定时任务2.将命令贴在所产生的事件旁边；3.有的命令可能产生多个事件，将它们

7、连接；4.在这个过程中可以识别出触发命令的外部系统（粉色即时贴）、persona（黄色即时贴）并进行表示；划分限界上下文命令风暴示例订单 已创建订单 已支付商城库存 已扣减仓库库存 已占用商品 已创建订单 已撤销商城库存 已增加出库单已 生成出库单已 发货投诉单 已创建投诉单已 处理商城库存 已编辑商品 已发布商品销售 价格已编辑订单 已发货补货申请 单已创建补货申请 单已审批入库单 已创建入库单 已入库订单 已签收订单已 确认收货仓库库存 已扣减仓库库存 已增加商品已 编辑退货单已 创建退货单已 审核订单已 退货入库单 已创建入库单 已入库仓库库存 已增加添加 商品支付宝 回调超过1小时 未

8、支付 编辑 商品产品运 营人员编辑库存编辑销售 价格发布商品 创建订单 扣减库存创建 出库单占用库存发货扣减库存发货收货撤销订单 增加库存创建 退货单审核 退货单创建 入库单入库增加库存买家系统系统系统出库单已 配货配货仓库 管理员仓库 管理员系统系统物流系统 回调超过48小时 未确认 买家买家系统买家订单 专员系统仓库 管理员退货系统系统创建 补货单审批补 货单创建 入库单入库增加库存仓库 管理员系统仓库 管理员系统处理投诉单创建 投诉单客服 人员客服 人员产品运 营人员产品运 营人员产品运 营人员产品运 营人员产品运 营人员寻找聚合事件风暴命令风暴寻找聚合什么是聚合？如何寻找聚合？聚合是一

9、组相关领域模型的集合，是用来封装业务的不变性。确保关联关系紧密的领域模型能够内聚在一起。1.按照事件顺序依次通过提问来分析：这个事件会改变的领域模型是什么？明确领域模型（简单理解就是事件中的涉及的业务名词）这个领域模型是否可以独立访问？如果是就是聚合 如果不能独立访问应该需要通过哪个领域模型来访问？当前领域模型就是与该可独立访问的领域模型为同一个聚合2.将命令贴在聚合的左面，是聚合的输入；事件贴到聚合的右面，是聚合的输出。3.再根据聚合的原则（下一页描述）来检验上面的划分结果是否匹配，如不匹配则基于划分原则并结合业务重新调整聚合。使用聚合的目的是封装业务的不变性，同时强迫大家尽可能的简化领域模

10、型之间的关联关系。在业务层面进行高内聚，低耦合的设计。为什么用聚合？划分限界上下文聚合示例添加 商品商品 已创建商品已 编辑编辑 商品商品销售 价格已编辑编辑销售 商品 已发布发布商品订单 已创建创建订单订单 已撤销撤销订单订单 已支付支付宝 回调商城库存 已编辑编辑库存商城库存 已扣减扣减库存商城库存 增加库存订单 已发货发货订单 已签收订单已 确认收货收货物流系统 仓库库存 已占用仓库库存 已扣减占用库存扣减库存创建 投诉单订单已 退货退货处理投诉单仓库库存 增加库存退货单已 退货单已 创建 退货单审核 退货单入库单 已创建入库单 已入库入库单 已入库创建 入库单入库创建 入库单补货申请

11、单已创建补货申请 单已审批创建 补货单审批补 货单出库单已 生成创建 出库单出库单已 配货出库单已 发货发货出库单仓库订单补货 申请单退货单入库单投诉单商品支付订单订单划分限界上下文事件风暴命令风暴寻找聚合划分限界上下文什么是限界上下文？如何探索限界上下文？业务的扩展会产生越来越多的领域模型，任何大型项目都会存在很多的领域模型。当不同领域模型对应的软件代码被放在一起后，软件就变得庞大且复杂，代码难于理解、且容易出现bug，所以需要通过限界上下文来明确定义领域模型的范围和职责。为什么使用限界上下文？限界上下文可以分为限界和上下文两个词来理解，限界：指一个界限，具体的某一个范围；上下文：场景、环境

12、；所以限界上下文是在某个场景或环境下的业务边界。该边界就是业务上的职责。1.基于前面输出的聚合和领域模型，判断这些领域模型要解决的业务问题，这些问题是否为同一个问题，如果是则放到一个限界上下文中（一个问题对应一个限界上下文），如果为否则拆分到不同的限界上下文中；2.如果一个聚合（领域模型）同时解决多个问题时，则需要根据限界上下文的划分原则（后面几页会详细描述）对聚合（领域模型）进行拆分，拆分后对应的领域模型划分到不同的限界上下文中；3.上面环节中所定义的问题大小（需考虑问题的变化原因、内在逻辑等）需与领域专家共同讨论完成。限界上下文示例销售子域客服子域仓储子域商品商品上下文投诉单投诉上下文物流

13、 回调物流上下文订单退货单订单上下文支付上下文支付宝 回调仓库库存库存上下文出库单入库单出入库上下文补货 申请单补货上下文物流子域每一个限界上下文都是在明确边界微服务设计原则1.对齐限界上下文2.业务变更频率与相关度3.系统非功能性需求4.组织结构和康威定律5.团队规模6.技术异构和现有系统复杂度服务画布已可视化阿 士大1.买家 2.商户1.买家创建订单 2.商户履行订单订单商品1.订单 2.商品 3.*明确服务的范围明确核心模型明确服务包含的数据表可视化的拆解遗留系统微服务架构、绞杀模式、代码依赖分析、数据库依赖分析、遗留系统拆解评分表、降龙八步庖丁解牛拆解的最高境界了解牛的生理构造避开筋腱

14、骨节交错的组织从骨节的缝隙下手十九年刀依然锋利再看一眼微服务架构我们要做应用代码拆分我们要做数据库拆分绞杀者模式“绞杀者模式”在既有系统资产的基础上实现数字IT创新，面对创新的数字IT业务更加灵活。通过在新的应用中实现新特性，保持和现有系统的松耦合，仅在必要时将功能从原系统中剥离，以此逐步地替换原有系统。修缮者模式“修缮者模式”在既有系统资产的基础上，通过剥离新业务和功能，逐步“释放”现有系统耦合度，解决遗留系统质量不稳定和Bug多的问题。实现传统IT性能提升，面对传统的IT业务更加稳定灵活，降低维护成本。修缮模式适用于需求变更频率不高的存量系统2018 ThoughtWorks Inc.Co

15、nfidential-please do not distribute.步骤3-聚合 32Digitalization is the use of digital technologies to change a business model and provide new revenue and value-producing opportunities;it is the process of moving to a digital business.面对巨大复杂的遗留系统，我们该如何开始拆解？代码依赖模式我们推荐以模块(java包)为基本单位，从代码依赖的角度看，有三种模式：packag

16、e A class X public void foo()Y.bar();依赖其他模块package B class Y public void bar()package A class X public void foo()package B class Y public void bar()X.foo();被其他模块依赖package A class X public void foo()独立存在 Structure101代码依赖分析可视化代码地图自动分析每一层级包/类之间的依赖生成可视化表格 Structure101代码依赖分析具体依赖细节 Structure101代码依赖分析可以将包/

17、类进行自由组合，形成容器，查看容器之间的依赖服务A服务B具体依赖细节已可视化 Structure101代码依赖分析与Intellij或Eclipse相结合，实时查看依赖，指导拆解过程已可视化数据库依赖模式模块AData Mapper/ORM相关联但不属于 模块A的表模块AData Mapper/ORM属于模块A的表以模块(java包)为基本单位，从数据库依赖的角度看，有两种模式：属于模块A 的表扫描数据库依赖UserMapper.javaUserMapper.xmlJAVA定义XML实现扫描数据库依赖服务名mapper名方法名正确依赖表名错误依赖表名用户服务com.xxx.UserMapper

18、getUserByIdUSERN/A用户服务com.xxx.UserMappergetUserProductsUserProduct数据库依赖统计表使用工具 扫描UserMapper.xml已可视化拆解该从那个服务开始？业务 复杂度需求变化频率使用 频度系统集成关系数据迁移量代码改动量拆解后 带来的收益（业务价值）拆解中的 工作量成本（技术成本）遗留系统拆解评分表业务 复杂度需求变化频率使用频度系统集成关系数据迁移量代码改动量业务维度 总体评分技术维度 总体评分改造意愿排名业务维度评分越高，表示越需要微服务化来更快、更好支撑业务需求，改造意义就越高技术维度评分越高，表示技术风险挑战越高，同时反

19、应出微服务化接触的空间越广越深服务A58855826104服务B服务C服务D已可视化遗留系统拆解给飞行中的飞机换引擎友谊第一 比赛第二降龙八步第一式用户订单商品第一式：1.明确要拆解的服务所涉及的模块 2.验证之前代码依赖分析和数据库分析的结果 3.约定“同一类型数据只有一处修改”，以数据为中心提高内聚性，同时避免写冲突的出现遗留系统降龙八步第二式用户订单商品遗留系统第二式：1.在现存订单模块中添加新的方法，提供给用户模块使用，删除用户模块直接使用订单模块的数据表 2.对用户模块和商品模块做同样的事情 3.需要在改动点添加自动化

20、测试保证功能正确 4.将数据库的join推到代码应用层面，势必会比原来慢，需要关注性能问题。考虑添加缓存，数据库索引，甚至调整服务划分来解决降龙八步第三式用户订单商品第三式：1.在订单模块中添加REST API，提供给用户模块使用，将用户模块对订单模块的代码依赖改成REST API依赖 2.对用户模块和商品模块做同样的动作 3.确保所有依赖用户模块，和使用用户模块的依赖点都改成REST API后在进行下一步，否则会导致系统进入中间状态遗留系统REST API降龙八步第四式用户订单商品第四式：1.将用户模块单独部署成独立运行的用户服务，同时引入微服务基础设施，如服务注册，服务发现，API Gat

21、eway等。2.确保新的用户服务链接原始数据库用户遗留系统微服务 基础设施降龙八步第五式用户订单商品第五式：1.修改商品模块，使用新的用户服务，修改用户服务使用订单模块 2.架空原有用户模块 3.出现问题随时切换回原始用户模块遗留系统用户微服务 基础设施降龙八步第六式用户订单商品第六式：1.给用户服务创建数据库，从原始数据库中同步用户服务的数据遗留系统用户微服务 基础设施同步数据降龙八步第七式第七式：1.配置用户服务，使用用户服务数据库 用户订单商品遗留系统用户微服务 基础设施降龙八步第八式订单商品遗留系统用户微服务 基础设施第八式：1.新用户服务运行一段时间后，删除原始用户模块，完成拆解遗留

22、系统拆解注意事项1.遗留系统改造过程中，适当减少新需求的开发，减少改造难度2.遗留系统改造过程中，新需求开发必须按照新规则，如只通过REST API进行依赖，同一类型数据只能在某一模块中修改，不依赖其他模块数据库等，减少改造工作量3.遗留系统中还会包含前端代码和存储过程，也需要通过代码依赖分析和数据库依赖分析进行拆解4.服务间依赖不一定只有REST API，可以通过异步消息、数据冗余等方式，根据实际情况进行选择5.部署新微服务后，推荐让新老系统并行一段时间，通过分流让少部分流量进入新微服务，确保改造更加安全总结C4模型领域驱动设计事件风暴工作坊Structure 101微服务架构遗留系统拆分https:/ https:/ http:/www.ddd- https:/ https:/ https:/ https:/ https:/ YOU