开发者所开发的服务实现的是不同的功能。业务特点不同，相应服务层的结构也会差异很大。本文讨论一些常见的模式：业务和技术功能、聚合和多元服务以及关键路径和非关键路径的服务。
业务和技术功能
1）业务能力是组织为了创造价值和实现业务目标所做的工作。划到业务功能的微服务直接体现的是业务目标。
2）技术能力通过实现共享的技术功能来支持其他服务。
如图，SimpleBank的order服务管理下单的功能——这是一个业务功能；而market服务是一个技术功能，它提供了和第三方系统通信的网关供其他服务使用（想调用market data和settlement可以通过market服务）。
聚合与多元服务
在微服务应用的早期阶段，多个服务可能是扁平化的，每个服务的职责都是处于相似的层次的，比如，下图中order服务、fee服务、transaction服务和account服务——都处于大致相当的抽象水平。
随着应用的发展，开发者会面临服务增长的两大压力：1) 从多个服务聚合数据来为客户端的请求提供非规范化的数据（如同时返回费用和订单信息）；2) 利用底层的功能来提供专门的业务逻辑（如发布某种特定类型的订单）。
随着时间的推移，这两种压力会导致服务出现层级结构的分化。靠近系统边界的服务会和某些服务交互以聚合它们的输出——我们将这种服务称为聚合器(aggregator)，除此之外，还有些专门的服务会作为协调器(coordinator)来协调下层多个服务的工作。
聚合器服务通过将底层服务的数据进行关联来实现查询服务，协调器服务会向下游服务发出各种命令来编配它们的行动。
在出现新的数据需求或者功能需求时，开发者要决定是开发一个新的服务还是修改已有的服务，这是开发者所面临的重大挑战。创建一个新的服务会增加整体的复杂度并且可能会导致服务间的紧耦合，但是将功能加到现有的服务又可能会导致内聚性降低以及难以替换。这是违背了微服务的基本原则的。
关键路径和非关键路径
随着系统的不断演进，有一些功能对顾客的需求和业务的成功经营来说越来越重要。比如，在SimpleBank公司的下单流程，order服务就处于关键路径，一旦这个服务运行出错，系统就不能执行客户的订单。对应地，其他服务的重要性就弱一些。即便客户的资料服务不可用，它也不大会影响开发者提供的那些关键的、会带来收入的部分服务。
关键路径上的服务越多，系统出现故障的可能性就越高。因为不可能哪个服务是100%可靠的，一个服务累积的可靠性是它所依赖的那些服务的可靠性的乘积。
但是微服务使得我们可以清楚地确定这些路径，然后对它们单独处理，投入更多的精力来尽可能提高这些路径的可恢复性和可扩展性，对于不那么重要的系统领域，则可以少付出一些精力。
总结，业务能力和技术能力让我对服务层有新的认识。聚合和协调可以看到系统的演进策略。关键路径和非关键路径，这个在微服务下体现的更淋漓尽致，比如所有业务功能都在一个容器中比在不同容器中的成功率会高很多，存在一个可靠性累积效应。这又不是说都要在同一个容器中是最好的，根据不同业务压力和技术演进，组织架构都有可能拆分不同。同时关键路径对于测试来说，测试讲究策略和偏重点的，要考虑投入产出。版本发布时也要考虑是不是关键路径上的问题。
摘取自 摩根·布鲁斯和保罗·A.佩雷拉的《微服务实战》
网友评论