社区微信群开通啦,扫一扫抢先加入社区官方微信群
社区微信群
工作中使用了微服务,接下来的一段时间里,我会写一系列的文章来介绍微服务架构,同时我也会在github上写一个microservices的应用框架(地址会在后续文章给出)。
上一篇文章详细说明了单一应用架构与微服务架构各自的优缺点,这篇文章是对
http://microservices.io/patterns/decomposition/decompose-by-business-capability.html和 http://microservices.io/patterns/decomposition/decompose-by-subdomain.html 的翻译和整理, 内容是讲解如何把应用拆分成服务: 根据业务能力拆分或者根据子域拆分。
微服务架构用两种方式来达到目的:
这些好处不是自动就能得到的,相反的,它需要我们对服务有一个仔细的划分。
一个服务必须足够小,使得可以被一个小的团队开发和测试。从面向对象设计那里学到的一个有用的方法是单一职责原则。
应用也要被一种合适的方法拆分,从而大多数新的和修改的需求只影响到单个service。因为影响到多个service的改动需要多个团队之间的合作,这会拖慢开发的速度。另一个面向对象设计的有效原则是共同封闭原则,它是说,因为同一个原因修改的类应该在同一个包中。这种思想在设计服务时也同样有效:每个变化应该只影响一个service。
业务能力是业务架构模型中的一个概念。业务模型经常对应于一个业务对象,比如说:订单管理负责订单,客户管理负责客户。
业务能力经常组织成一个多层等级。比如说,一个企业应用也许有顶级的分类,如产品开发、产品交付、需求挖掘等。
一个在线商城的业务能力包括:
对应的微服务架构会有一些服务对应于这些业务能力:
这种模式有以下好处:
如何定义业务能力?定义业务能力和服务需要对业务有一个好的理解, 需要对组织的目标、结构、业务流程做一个分析。定义业务能力的好的开始点是:
一个在线商城的子域包括
对应的微服务架构会有一些服务对应于这些子域。
这种模式有以下这些好处:(与上面的方法一样的)
如何定义子域?定义子域和服务需要对业务有一个好的理解, 需要对组织的目标、结构、业务流程做一个分析。定义子域的好的开始点是:
如果觉得我的文章对您有用,请随意打赏。你的支持将鼓励我继续创作!