⽀持多业务线的微服务平台架构
如果无法正常显示,请先停止浏览器的去广告插件。
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
更多技术干货
欢迎关注“美团技术团队”