漫画:SOA中怎样确定服务的粒度?

简介: 一般系统的服务划分有以下两种维度:按模块划分这个比较适用于偏业务的场景:复杂的系统,最好先按业务领域横向拆分成可独立部署的子系统,每个子系统内部再按技术纵向拆分成不同的子模块。按角色划分这个比较适用于基础服务类的场景:一个大系统,每个服务看起来关联都很紧密,存在相互的调用关系。这时候可以考虑它们各自承担的角色和使命。

12132328-ffee918c81ac5c37.jpg


一般系统的服务划分有以下两种维度:


按模块划分


这个比较适用于偏业务的场景:复杂的系统,最好先按业务领域横向拆分成可独立部署的子系统,每个子系统内部再按技术纵向拆分成不同的子模块。


按角色划分


这个比较适用于基础服务类的场景:一个大系统,每个服务看起来关联都很紧密,存在相互的调用关系。这时候可以考虑它们各自承担的角色和使命。


12132328-19f18119904ab580.jpg


核心原则


单一职责:能不能用一句话说清楚这个服务的职责?非要分成两句话,那就分成两个服务。


在核心原则的基础上,符合下面的原则是一个比较好的实践:


松散耦合原则

可复用性原则

服务自治原则

可发现性原则

可组合性原则


   服务自治、可发现性相对难理解一些,展开一下。


服务自治


当一个服务的逻辑单元由自身的领域边界内所控制,不受其他外界条件的影响(外界条件带有不可预测性),且运行环境是自身可控,完全自给自足,我们认为这个服务是自治的。


自治的服务自身可以很好的对稳定性做把控。


可发现性


因为服务是被用来复用的,如果在服务设计过程中,并不能发现一个已经存在的服务,而需要重新建立多个同样逻辑元旦的服务,会极大增加管理和维护成本。


服务发现主要有两种:


1.设计时发现(人)


服务设计人员和研发人员在研发一个新的服务时,可以通过搜索服务仓库的元数据信息,查看服务仓库是否已存在此服务,没有才重新开发。


2.运行时发现(程序)


服务的消费者可以通过服务注册中心查到特定服务的接口调用地址调用。


12132328-8c9ab140324eb130.jpg



要根据系统的规模和人员配置情况。


比如如果系统一个系统的日活跃用户在万级和千万级,粒度肯定是不一样的。同样,基于系统规模带来的产出,那么开发人员数量也会相应不同。比较好的一个实践是一个人独立负责一个到两个服务。多人维护一个服务,交互成本非常高。


12132328-37f0f493b225720e.jpg

相关文章
|
7月前
|
敏捷开发 消息中间件 测试技术
微服务面试必读:拆分、事务、设计的综合解析与实践指南
微服务的应用级别确实相对简单,但在实际开发中仍有一些技术难点需要解决。对于微服务组件的使用,确实不存在太大差距,但在设计和开发过程中需要积累经验。学习微服务的上手时间相对较短,可能只需一周到一个月的时间。然而,设计经验和技术难点是需要个人长期积累的,不能急于求成。因此,在使用和开发微服务时,更应该关注方案思考,展示自己对该领域的理解和见解。这样能够体现出你对问题的思考深度和解决方案的创新性。希望这次面试种子题目的解答能够帮助你应对面试官的问题!
|
前端开发 小程序 Java
DDD实战之八:冲刺 1 战术之聚合设计(下)
DDD实战之八:冲刺 1 战术之聚合设计(下)
DDD实战之八:冲刺 1 战术之聚合设计(下)
|
前端开发 测试技术 定位技术
DDD实战之八:冲刺 1 战术之聚合设计(上)
DDD实战之八:冲刺 1 战术之聚合设计(上)
DDD实战之八:冲刺 1 战术之聚合设计(上)
|
架构师 程序员 微服务
|
架构师 前端开发 测试技术
为了成为一名架构师必须稳扎稳打,软件架构设计的模块划分
之前,我们在开发的时候总是惯性思维的以某张业务表的维度进行三层结构的功能开发,没有去思考他们功能模块间的关系,只是为了完成目标而进行开发。
|
缓存 监控 Dubbo
三万字图文归纳整理分布式系统微服务(二)
三万字图文归纳整理分布式系统微服务(二)
三万字图文归纳整理分布式系统微服务(二)
|
SQL NoSQL Java
三万字图文归纳整理分布式系统微服务(三)
三万字图文归纳整理分布式系统微服务(三)
三万字图文归纳整理分布式系统微服务(三)
|
存储 负载均衡 监控
三万字图文归纳整理分布式系统微服务(一)
三万字图文归纳整理分布式系统微服务(一)
三万字图文归纳整理分布式系统微服务(一)
|
缓存 数据库
缓存架构设计细节二三事
本文主要讨论这么几个问题:“缓存与数据库”需求缘起、“淘汰缓存”还是“更新缓存”、缓存和数据库的操作时序、缓存和数据库架构简析。
2277 0