⽀持多业务线的微服务平台架构

1. ⽀持多业务线的微服务平台架构

2. 收银技术中⼼-⾼级架构师著有《分布式服务架构：原理、设计与实战》和《可伸缩服务架构：框架与中间件》两本书。有近10年互联⽹、游戏和⽀付相关的⼯作经验，⽬前从事产业互联⽹。

3. 1 不同问题需要不同的架构 2 微服务架构的基本功介绍 3 微服务架构实战演练经验 4 打造会员营销平台型架构

4. 1 不同问题需要不同的架构 2 微服务架构的基本功介绍 3 微服务架构实战演练经验 4 打造会员营销平台型架构

5. 我过往的经历情况类型：传统互联⽹类型：互联⽹模式：企业级架构模式：单体服务架构类型：游戏类型：互联⽹⾦融模式：游戏架构模式：中台架构

6. 钢铁元帅--SLG的⼆战题材⻚游

7. ⼤圣顶住--TD⻄游题材⼿游

8. 不同类型的游戏特征对于每种类型的游戏通常都有⼀种架构解决⽅案——不同的游戏引擎

9. 不同类型的互联⽹架构特征

10. 微服务架构能满⾜不同规模的业务复杂度吗

11. 技术和业务复杂度的思考业务复杂⾯临的问题⼈的问题技术复杂⾯临的问题三⾼问题

12. 1 不同问题需要不同的架构 2 微服务架构的基本功介绍 3 微服务架构实战演练经验 4 打造会员营销平台型架构

13. 美团RMS业务的挑战业务复杂商家个性化需求多餐饮业业态⾮常多稳定性⾼⽆法接受系统不可使⽤各业态尽量相互不影响

14. 解决复杂规模系统的指导思想—抽象&分治&DDD 复杂规模混沌架构系统灵活可伸缩&⾼性能&⾼可⽤的服务化系统

15. 解决复杂规模系统的推荐⽅法—伸缩⽴⽅模型⽆论是偏向理论的思维意识⽅法，还是技术维度分离⽅法，本质上都是追求⾼响应⼒，降低复杂性和应对不确定性⼿段，服务化是⼀个较好的实践⽅式。在《The Art of Scalability》中，提出⼀个伸缩⽴⽅模型（Scale Cube）。 X轴扩展：运⾏多个相同的⼀个应⽤以此来实现负载均衡，如果有N个相同的应⽤部署，那么每个单独的应⽤只需要处理1/N 份的负载请求。 Y轴扩展：尽可能的拆分⼀个单独的应⽤成多个不同的服务。每个不同的服务则负责⼀个到多个相近的功能模块。 Z轴扩展：每个服务器仅仅拥有或负责⼀部分数据。Z轴的拆分通常就是针对数据库的扩展，数据根据⼀定的特征被分区在不同的分区服务器上。

16. 如何进⾏服务化？对于新业务系统或⽼业务模块，如何进⾏服务化设计中改造？对于服务如何拆分，以及拆分的粒度多⼤才是合理的？要很好的回答上⾯问题，我们必须从⼀些软件设计⽅法中寻找。反过来，如果不关注设计的合理，领域分析设计和系统抽象做不好，微服务化后会把这个问题成倍的放⼤。

17. ⾯向服务设计的先驱指导思想微服务中的不同服务之间通过定义良好的接⼝和契约联系起来。接⼝是采⽤中⽴的⽅式进⾏定义的，它应该独⽴实现服务的硬件平台、操作系统和编程语⾔，这使得构建在各种系统中的服务可以以⼀种统⼀的通⽤的⽅式进⾏交互。著名SOA专家Thomas Erl的归纳如下：

18. 微服务推荐最佳实践微服务架构由⼀组⼩型的、独⽴⾃治的服务组成，并且实现了业务中单个的业务功能。 •服务和服务之间是独⽴的、低耦合的； •每个服务都尽量⼩，⼩到⼀个⼩团队能够很好的维护它； •服务可独⽴部署，每次部署不会影响其他服务； •每个服务都各⾃负责⾃⼰的数据和状态的存储，独⽴数据库； •服务和服务之间通过设计良好的API接⼝通信，不暴露具体的实现细节； •各服务不需要统⼀技术栈，不需要共享公共库和框架；

19. 微服务是服务化思想的延续和改进⾯向服务架构（SOA）微服务架构（MSA）尽可能多的共享和复⽤ share-as-much-as-possible 尽量少的共享和复⽤ share-as-little-as-possible 要求统⼀和标准化 common governance and standards 提倡协作和⾃由 people collaboration and freedom 服务间通过企业服务总线ESB通信 Enterprise Service bus (ESB) 服务间使⽤轻量级的HTTP/REST通信 lightweight protocols such as HTTP/REST 可能共享数据存储 Share Data 具有独⽴的数据存储 Data isolation 依赖很多中间件 Middleware component 独⽴⾃治的轻量级服务 small autonomous services

20. 微服务设计的基本原则软件设计相关原则服务⾃治：最⼩完备、独⽴演进

21. 微服务设计的推荐⽅法

22. 微服务划分的⽅法—DDD的限界上下⽂ Eric Evans的⼀个⽐喻⾮常形象：“细胞之所以会存在，是因为细胞膜定义了什么在细胞内，什么在细胞外，并且确定了什么物质可以通过细胞膜”。⼀个具有有限的业务范围，可以帮助我们敏捷地开发和交付价值。那么什么样的业务边界是合适的？

23. 微服务划分的⽅法—DDD的限界上下⽂ DDD的概念和技术很好的指导服务化实践服务的划分过程类似于BC的划分过程划分确定了核⼼领域，限界上下⽂也就确定了 1个微服务<=1个BC，避免服务内的领域歧义 1个微服务>=1个聚合，避免引⼊分布式事务的复杂度 Tips 划分的⼦域和服务需满⾜正交原则，领域名字代表的⾃然语⾔上下⽂保持互相独⽴限界上下⽂（Bounded Context）的核⼼就是同⼀个领域上下⽂中的模型要保持⼀致性，即同⼀个将特定职责的相关⾏为控制在⼀个有限的边界业务。范围内。所以识别出合理的限界上下⽂，就能对服务合理进⾏拆分。

24. 微服务划分的⽅法—关注点分离每个⼈能够认知的复杂度都是有限的，在⾯对⾼复杂度的时候我们会做关注点分离，这是⼀个最基本的哲学原则。将复杂问题做合理分解，再针对不同侧⾯进⾏专注处理

25. 微服务划分的⽅法—基于痛点和经验限界上下⽂和关注点分离，本质上都是从业务视⻆去分离复杂度的⼿段，那么只要从降低复杂度、解决痛点，也可以达到同样⽬的。集合划分、从⼤到⼩，切断耦合分离、提升当业务不是很清晰，不确定是否拆分的时候，建议先尽量不做拆分，由⼤到⼩的拆分总是⽐合并重构容易

26. 服务拆分应当做好权衡从业务领域⻆度切分，⾮团队⻆度，否则会出现抢地盘，破坏团队信任。拆分后的维护成本是否降低。服务拆分的⽬的是为了更好的服务治理，把逻辑复杂的问题分散到各个服务以降低整体复杂度和架构⻛险。如果划分错误就会陷⼊⼤量服务间的相互调⽤和引起分布式事物问题。我们应该关注服务的范围，⽽不是⼀味地把服务拆⼩，⼀个好的实践是先从⼀个⽐较⼤的服务边界开始，随着时间推移基于业务需求来重构成更⼩的服务。服务内模型与其他服务模型或⻆⾊关系的紧密程度，可侧⾯验证我们服务划分的是否合理。

27. 1 不同问题需要不同的架构 2 微服务架构的基本功介绍 3 微服务架构实战演练经验 4 打造会员营销平台型架构

28. 会员营销架构设计的背景痛点问题服务划分太多，调⽤链太⻓分布式问题严重，经常对不上账时间选择新接⼿另⼀个会员系统部⻔提倡消灭重复烟囱

29. 运⽤“四步三⾯法”进⾏微服务架构划分—四阶段业务建模定义限界上下⽂ DDD限界上下⽂法定义领域对象和领域服务定义微服务关注点分离法痛点、经验法

30. 运⽤“四步三⾯法”进⾏微服务架构划分—三个层⾯

31. 会员营销微服务架构实践案例步骤⼀：业务建模

32. 业务建模：什么是建模？太阳系⼋⼤⾏星

33. 业务建模：游戏中的⼈物模型可视化展示掌趣旗下上游科技的「⼤圣顶住」

34. 业务建模：游戏中的⼈物建模技能 - 触发条件 - 技能⾏为 * 1 背包武将 1 - 道具 1 - 礼包 - 品级 - 描述 1 - 属性 + ⼀级属性 + 三级属性 1 1 * * 道具装备 1 * + ⼆级属性 - 技能 - 背包 * 属性 + ⼀号位 + ⼆号位 + 三号位

35. 业务建模：模型提炼经验和⽅法总结

36. 业务建模：案例场景⼀个顾客在店⾥吃完饭，结账时服务员告诉可以办理会员卡从⽽能打折。服务员：你是想办⼀张普通会员卡，还是办⼀张⿊⾦卡？顾客：有什么不同吗？服务员：不同等级的会员卡优惠不⼀样，享受的活动也不同。顾客：那我办张⿊⾦卡吧。服务员：好的，请提供下电话号码、姓名和⽣⽇信息下，⽣⽇当天还可以享受⽣⽇活动。顾客：我可以办多张会员卡吗？送亲戚朋友。服务员：可以的。

37. 业务建模：⽤例分析输⼊姓名 Include 会员管理 Include 输⼊电话号码营销系统 Include 会员⽣⽇服务员会员卡管理 Include Include 选择卡类型 Extend 创建会员卡⽣⽇活动

38. 业务建模：会员模型示意图

39. 会员营销微服务架构实践案例步骤⼆：限界上下⽂划分

40. 限界上下⽂划分：采⽤DDD战略建模和团队划分会员团队营销团队

41. 会员营销微服务架构实践案例步骤三：定义领域对象和领域服务

42. 定义领域对象：采⽤DDD战术建模实现业务的“⾼内聚” 限界上下⽂ Factory Aggregate Entity + create() Aggregate + save() + get() Serializer Tunnel SPI

43. 会员营销微服务架构实践案例步骤三：定义微服务

44. 定义微服务：综合权衡演进实现服务的“低耦合” 服务设计原则正交四原则 SOLID原则问题分析痛点问题读写分离稳定和易变快慢分离

45. 微服务架构⼩结开始介绍了微服务架构的理论知识，主要包括设计的基本原则和划分⽅法然后通过“ 四步三⾯法 ”详细的为⼤家分享了会员营销的实践经验

46. 1 不同问题需要不同的架构 2 微服务架构的基本功介绍 3 微服务架构实战演练经验 4 打造会员营销平台型架构

47. 会员营销架构平台化发展的背景⽀持多业务产线快速创新试错各业务的流程不同快速适配新的业务需要⽀持⾃定义扩展可“插拔”的标准化

48. 业务平台型架构业务1 业务2 通⽤平台能⼒业务3 业务4 ⾃定义扩展

49. ⾯向不确定性架构外沿确定性内核确定性

50. 未来规划插件和插件隔离插件和平台隔离平台和框架隔离

51. 总结⾯对不同规模复杂系统的架构是不⼀样的，通过“ 四步三⾯法 ”来设计微服务架构；当系统发展成平台型时，就需要核⼼能⼒下沉和可扩展的“ ⾯向内核稳定 ”架构设计；

52. Q&A

53. 招聘：Java专家及以上岗位邮箱： wangying49@meituan.com 更多技术干货欢迎关注“美团技术团队”