标签:img 多个 另一个 速度 订单 微服务架构 库存 团队 客户
您正在开发一个大型,复杂的应用程序,并希望使用微服务架构。微服务架构将应用程序构建为一组松散耦合的服务。微服务架构的目标是通过实现持续交付/部署来加速软件开发。
微服务架构以两种方式实现:
这些好处不会自动得到保证。相反,它们只能通过将应用程序细致地功能分解为服务来实现。
服务必须小到足以由小团队开发并且易于测试。面向对象设计(OOD)的一个有用的指导原则是单一责任原则(SRP)。SRP将类的责任定义为改变的理由,并声明类只应有一个改变的理由。将SRP应用于服务设计以及设计具有凝聚力的服务并实现一小组强相关功能是有意义的。
应用程序也以某种方式进行分解,以便大多数新的和更改的要求仅影响单个服务。这是因为影响多个服务的更改需要跨多个团队进行协调,这会降低开发速度。OOD的另一个有用原则是Common Closure Principle(CCP),它声明由于同样的原因而改变的类应该在同一个包中。例如,也许两个类实现了同一业务规则的不同方面。目标是当业务规则改变开发人员时,只需要更改少量代码(最好只有一个)的代码。在设计服务时,这种想法很有意义,因为它有助于确保每项更改只影响一项服务。
如何将应用程序分解为服务?
定义与业务功能相对应的服务。业务功能是业务架构建模的概念。这是企业为了创造价值所做的事情。业务能力通常对应于业务对象,例如业务对象。
业务功能通常组织为多级层次结构。例如,企业应用程序可能具有顶级类别,例如产品/服务开发,产品/服务交付,需求生成等。
在线商店的业务能力包括:
相应的微服务架构将具有与这些能力中的每一个相对应的服务。
这种模式具有以下好处:
有以下问题需要解决:
如何识别业务能力?识别业务能力和服务需要了解业务。通过分析组织的目的,结构,业务流程和专业领域来识别组织的业务能力。使用迭代过程可以最好地识别有界上下文。识别业务能力的良好起点是:
标签:img 多个 另一个 速度 订单 微服务架构 库存 团队 客户
原文地址:https://www.cnblogs.com/paxlyf/p/11293812.html