微服务（二）

作者：James Lewis/Martin Folwer
翻译：Zhang Yang

围绕业务功能组织

仔细看大型应用程序分成的几个部分，往往管理的重点在技术层面上，产生用户界面团队，服务器端功能团队和数据库团队。当这些团队沿着这些线路分开，即使是简单的改变也可以导致一个跨团队项目，需要花费时间和预算。一个聪明的团队将优化解决这个，两害取其轻-强迫分配业务到它涉及到应用程序中。业务逻辑无处不在。这里有一个Conway’s Law in action[5]的例子。

任何组织，它设计一个系统（广义上的），会产生这样的设计：其结构将复制组织的通信结构。
- 梅尔文·康威，1967年

图2：Conway’s Low in action

微服务的分工方法是不同的，围绕业务功能分解成多个服务。这些服务为业务领域采取软件的宽栈实现，包括用户界面，持续性存储和外部协作。因此，团队是跨职能的，包括全方位的所需开发技能：用户体验，数据库和项目管理。

图3：团队边界加强服务边界

www.comparethemarket.com以这种方式进行了组织。跨职能团队负责建设和经营的每个产品，每个产品拆分为多个独立的服务通过消息总线进行通信。

大型整体件应用程序也可以始终围绕业务功能模块化，虽然这不是常见的情况。当然，我们可以要求一个庞大的队伍，来建设整体件应用，依据业务线划分自身职能。我们在这里看到的主要问题是，他们往往是围绕了太多的上下文。如果整体件跨越许多模块化的边界，可能很难要求团队的成员用他们的短期记忆，处理他们面对的状况。此外，我们看到，模块化线路需要大量的纪律约束。服务组件必需的间隔越明确，团队边界越容易清晰。

产品没不是项目

我们看到的绝大多数软件开发使用项目模型：其目的是发布一些的软件片段，然后视其为完成。完成了的软件会交给维护团队，项目团队解散。

微服务的支持者倾向于避免这种模式，而愿意应该在产品的整个生命周期中，让一个团队拥有一个它。一个常见的启示是亚马逊的口号，“ you build，you run it”，那里一个开发团队需要对生产的软件的负全部的责任。这使开发者不得每天都关心产品中他们的软件行为，并增加与用户的接触，因为他们必须承担至少部分的支持工作。

产品的心态，关系到商业能力。与其将软件视为一套完成的功能组合，不如将其视为一段与用户的持续的联系，期间关注软件如何协助用户增强商业能力。

不知道为什么整体件应用程序不能采取同样的方法，但更小粒度的服务可以更容易地建立,开发人员和用户之间的人际关系。

智能终端和沉默管道

在构建不同进程之间的通信结构时，我们已经看到很多的产品和方法，它们强调将智能放入通信机制本身。这方面的一个很好的例子就是企业服务总线（ESB），它往往提供复杂的工具，用来消息路由，编排，转换和商业规则。

微服务社区赞成另一种方法：智能终端和沉默管道。依据微服务构建应用程序的目标是尽可能的去耦和，内聚性地–他们拥有自己的业务逻辑，像经典的Unix意义上的过滤器一样行为–接收请求，恰当的应用业务逻辑，并产生一个响应。这里使用简单的RESTish协议，而不是复杂协议如，WS-编舞或BPEL或业务流程编排，或者中央控制式。

最常用的两个协议是带资源API的HTTP请求-响应和轻量级通信[6]。前一个最好的表述是：

就是Web，而不是在Web后面
- 伊恩·罗宾逊

微服务团队使用的原则，也是万维网（并在很大程度上Unix也是）的基础。通常使用的资源可以被缓存，而开发/运营人员只需要花费很少的时间。

第二种方法常见于通过轻量级消息总线通信，它的基础选择通常是沉默式的（沉默得只充当消息路由器） -如RabbitMQ或ZeroMQ一样的简单实现，仅仅提供了可靠的异步媒介 – 在服务中，智能的终端产生和消费信息。

在整体件中，组件们在进程中执行，通过方法调用或者函数引用进行通信。将整体件改成微服务的最大的问题在于改变通信模式。单纯的从内存方法调用转换到RPC会导致表现很差的繁琐通信。相反，你需要用一个粗糙粒度通信方法代替精细的方法。

备注：
5: The original paper can be found on Melvyn Conway’s website here
6: At extremes of scale, organisations often move to binary protocols - protobufs for example. Systems using these still exhibit the characteristic of smart endpoints, dumb pipes - and trade off transparency for scale. Most web properties and certainly the vast majority of enterprises don’t need to make this tradeoff - transparency can be a big win.

转载于:https://my.oschina.net/windmissing/blog/690455