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

如果无法正常显示,请先停止浏览器的去广告插件。
分享至:
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 更多技术干货 欢迎关注“美团技术团队”

trang chủ - Wiki
Copyright © 2011-2024 iteam. Current version is 2.137.1. UTC+08:00, 2024-11-13 19:50
浙ICP备14020137号-1 $bản đồ khách truy cập$