在对复杂的业务系统进行微服务的拆分时应该注意什么

  • 时间:
  • 浏览:0
  • 来源:uu快3漏洞_uu快3链接_公式

白岳

原文地址:http://blog.720ui.com/2017/msa_design/

总结下,服务的拆分是另一一三个非常有学问的技术活,要围绕业务模块进行拆分,拆分粒度应该保证微服务具有业务的独立性与完整篇 性,尽以前 少的居于服务依赖,链式调用。因此,在实际开发过程中,有的以前 单体架构更加适合当前的项目。实际上,微服务的设计并有的是 一蹴而就的,它是另一一三个设计与反馈过程。因此,亲戚亲戚让当他们 在设计之初能都都里能了将服务的粒度设计的大一些,并考虑其可扩展性,随着业务的发展,进行动态地拆分也是另一一三个不错的挑选。

微服务要怎么拆分,是否拆分粒度越小越好?一般状况下,对于服务的拆分暂且越小越好,甚至极端的案例是把一块功能拆分成另一一三个服务,这个 做法是不对的。因此,拆分粒度应该保证微服务具有业务的独立性与完整篇 性,服务的拆分围绕业务模块进行拆分。类事将 VR 资讯系统进行服务拆分,分为资讯系统、话题系统、日报系统、百科系统五个微服务系统。

因此,如果状况下,服务的拆分围绕业务模块进行拆分是并有的是理想状况下的拆分土土方法,换句话说,亲戚亲戚让当他们 在架构设计 之初就假定亲戚亲戚让当他们 能都都里能了掌握一切。然而,不同的服务以前 由不同的团队开发与维护,实际场景下,微服务的便利性更多的在于团队内部内部结构都都里能产生闭环,换句话说,团队内部内部结构能都都里能了易于开发与维护,便于沟通与相互媒体合作,因此对于内部内部结构团队就居于很大的沟通成本与相互媒体合作成本。现在,亲戚亲戚让当他们 来看另一一三个案例。团队 A 考虑到功能的复用性而开发了另一一三个“互动组件”,其中包括 “评论模块”功能。此时,团队 B 暂且知情也开发了另一一三个类事的“互动组件”。而团队 C 有的是 这个 需求,它知道团队 A 有这个 “互动组件”,希望能都都里能了复用,因此以前 这个 “互动组件”在设计的以前 更多地考虑了团队 A 的当前业务,这样 很好的复用性,类事不支持“评论盖楼”功能,而以前 团队 A 出于当前一些项目的进度由于无法马上提供支持,团队 B 评估后决定花一周时间自己开发另一一三个符合自己业务需求的“互动组件”。此时,各个项目团队人个维护了另一一三个“互动组件”。此外,亲戚亲戚让当他们 再来看另一一三个案例。另一一三个 OA 系统拥有“用户管理”、“文件管理”、“公告管理”、“政策管理”、“公文管理”、“任务管理”、“审批管理”等功能,以前 按照微服务架构思想能都都里能了围绕业务模块进行拆分,因此事实上这个 OA 系统的最终用户都都里能了 1000 多人,使用微服务架构以前 不怎么“杀鸡用牛刀”的感觉了。回顾下,第另一一三个案例中,以前 团队之间的职责与边界由于了服务的复用居于局限性,甚至造成人个为战的局面,这个 状况一般时要公司层面进行规划和统筹。第二案例中,以前 用户量不大,系统如果错综复杂,使用微服务反而带来了暂且要的设计和运维难度,一块儿也带来了一些技术的错综复杂度。此外,亲戚亲戚让当他们 还时要考虑服务依赖,链式调用、数据一致性、分布式事务等什么的大问题。