4.14.6 —种混合方式

 

前面提到的那些选择各自都有其适用的范围。一个组织会选择基于片断组装的方式来构建 网站，但对于移动应用来讲，BFF多是更好的方式。关键是要保持底层服务能力的内聚 性。好比，预约音乐和改变客户信息的逻辑应该处在相应的服务中，避免这些逻辑在系统中处处散布。将太多的逻辑放入到刚才提到的那种中间层中是一个常见的陷阱，在实际中 须要很是当心地作权衡来避免这个问题。

 

4.15与第三方软件集成

 

前面提到的拆分已有系统的方式针对的是咱们本身开发的系统，但若是须要处理那些不受 咱们控制的系统呢？因为种种缘由，和咱们一块儿工做的组织都购买了 COTS或者利用SaaS (Software as a Service,软件即服务平台），而一般咱们对这些系统的控制力都颇有限。那 么如何合理地与之进行集成呢？

 

若是你正在阅读此书，那么你颇有可能工做在一个须要写代码的组织中。你可能为内部或 者外部的用户编写软件，或者二者皆有。无论怎样，即便你所在的组织拥有很强的定制化 软件开发的能力，你仍是须要外部组织提供的商业或者开源软件产品。为何会这样呢？

 

第一，你的组织对软件的需求几乎不可能彻底由内部知足。考虑你使用的全部产品，从类 似Excel的办公自动化工具到操做系统，再到工资系统。本身建立全部这些产品的工做量 是巨大的。第二，也是最重要的一点是，这样作很是低效！本身构建邮件系统的代价要远 远大于使用现成的工具，即便选用的是商业工具。

 

个人客户常常纠结这样的问题：“应该本身作，仍是买？ ” 通常来说，我和同事的建议是， 对于通常规模的组织来讲，若是某个软件很是特殊，而且它是你的战略性资产的话，那就 本身构建；若是不是这么特别的话，那就购买。

 

举个例子，通常规模的组织不会把工资系统看成它的战略性资产，由于全世界的人领工 资的方式都大同小异。相似地，大部分组织倾向于购买现成的CMS (Content Management System,内容管理系统），由于这一类工具对它们的业务来讲并非那么关键。我参与过 Guardian网站的早期构建工做，定制的内容管理系统对于新闻行业来讲很是关键，因此他 们决定本身构建。

 

因此，使用一些商业的第三方软件是合情合理的，但不少人会逐渐开始咒骂这些系统，这 又是为何呢？

 

4.15.1缺少控制

 

使用相似CMS和SaaS这样的COTS产品会面临的一个挑战是，如何与之进行集成并对其 进行扩展，由于大部分技术决策都不受你的控制。如何与该工具进行集成？厂家决定的。 使用什么编程语言对其进行扩展？也取决于厂家。你是否可以把该工具的配置文件存到版 本管理中，而后在持续集成中从新建立和配置该工具？这依赖于厂家所作的决定。

 

若是你足够幸运，从开发的角度使用该工具的难易程度会成为工具选择流程中的一个考虑因素。但即使如此，你仍是放弃了一部分控制。因此更好的方式是，尽可能把集成和定制化 的工做放在本身可以控制的部分。

 

4.15.2定制化

 

不少企业购买的工具都声称能够为你作深度定制化。必定要当心！这些工具链的定制化往 往会比从头作起还要昂贵！若是你决定购买一个产品，可是它提供的能力不彻底适合你， 也许改变组织的工做方式会比对软件进行定制化更加合理。

 

内容管理系统可以很好地说明这种危险。我用过的不少CMS工具设计上就不支持持续集 成，其提供的API很是难用，而且底层工具很小的升级都会破坏你作的那些定制化。

 

Salesforce的问题尤为突出。这么多年来它一直在推 Force.com平台，而这个平台须要使用 一种叫做Apex的语言，该语言只能应用在 Force.com的生态系统中。

 

4.15.3意大利面式的集成

 

另外一个挑战是如何与工具进行集成。如前面讨论过的，服务之间的集成是一件很是重要的 事情，理想状况下应该存在一些为数很少的标准化集成方式。但若是一个产品决定使用专 有的二进制协议，另外一个使用SOAP，还有一个使用XML-RPC，你该怎么办？更糟糕的 是，那些容许你直接访问其内部数据存储的工具，会引人前面讨论过的那些耦合问题。

 

4.15.4在本身可控的平台进行定制化

 

COTS和SAAS产品固然是有用的，但不适用于重头开始构建系统的场景（或者说这么作 不合理）。那么如何解决这些挑战呢？关键是把事情移到本身可控的部分作。

 

核心思想是，任何定制化都只在本身可控的平台上进行，并限制工具的消费者的数量。为 了更好地理解这个概念，接下来看两个例子。

 

1.例子：CMS做为服务

 

从个人经验来看，CMS是一个最常常须要作定制化或者与之集成的产品。由于除非你想要 的是基本的静态站点，不然通常的企业都但愿在本身的网站上提供动态内容，好比客户信 息或最新的产品。这些动态内容的来源一般是组织内已经存在的其余服务。

 

CMS最多见的卖点是，你能够对其进行定制化，从而把各类特殊的内容放进来并显示给外 部世界。然而普通的CMS开发环境一般都很是糟糕。

 

普通的CMS提供的主要功能是内容的建立与管理。大多数CMS甚至连页面布局都作很差， 它们一般只提供一些可拖拽的工具，然而这并不能知足你的需求，你还须要一些懂HTML 和CSS的人来好好调整CMS模板。在其之上开发定制化代码将会是很是糟糕的体验。

 

那么到底应该怎么办呢？你能够选择在CMS上面套一层本身的服务做为对外的网站，如 图4-11所示。这时CMS就成为了一个服务，其职责是管理内容的建立和获取。在本身写 的那个前端服务中，你能够按照本身的方式来写代码和作集成。你对网站的扩展具备很好 的控制力（不少商业CMS提供了本身专用的插件来处理负载），那么就可使用更合理的 模板系统。

图4-11:使用CMS把你本身的服务隐藏起来

 

大多数CMS还提供了建立内容的API，因此你能够选择把建立的这部分也使用本身的服 务包裹一层。在曾经作过的一些项目中，咱们甚至使用过一个外观（fapde)对获取内容 的API进行抽象。

 

前几年，在ThoughtWorks这种模式应用得很普遍，光是我本身就作过不止一次。一个值 得注意的例子是这样的：一个客户想要为他的产品制做一个网站，刚开始他想彻底在CMS 上构建这套系统，但还没肯定使用哪一个。就在这时咱们建议了这种方式，而后开始构建前 端网站。在CMS选定以前，用一个假的静态内容服务来替代它。后来甚至在CMS肯定之 前，直接在生产环境使用了该静态内容服务。等到CMS终干选好了以后，没有作任何修 改就顺利地把原来的服务给替换掉了。

 

这种方法吋以最大程度地限制CMS的使用范围，并把定制化的工做移到你本身的技术 栈中。

 

2.例子：多职责的CRM系统

 

咱们还常常会遇到CRM (Customer Relationship Management,客户关系管理）工具，即 使最坚强的架构师也会对它感到恐惧。这个行业的主要厂家包括Salesforce和SAP，这些 工具试图为你包揽全部的事情。因此这些工具可能会出现单点失败，而且还可能会变成一 团乱七八糟的依赖。我见过的不少CRM工具的实现都是粘性（内聚性的反方向）服务的 典范。

 

这种工具的使用范围每每一开始会比较小，但随着时间的发展它会在你的组织中变得越来 越重要，以致于后续的方向和选择都会围绕它来作。但这么重要的系统居然不是本身作 的，而是第三方厂家提供的，这是个很严重的问题。

 

我最近在作的一件事情就是夺回控制权。我所服务的组织意识到虽然不少事情都使用 CRM在管>里，可是这个平台并无带来与其代价相对应的收益。与此同时，不少内部系 统都在使用CRM提供的差强人意的API来作集成。咱们但愿对系统架进行演化，使用自 己的服务来对业务进行建模，从而为潜在的迁移打下基础。

 

咱们作的第一件事情是，识别出正在被CRM系统控制的核心领域概念。其中之一是“项 目”的概念，员工会被分配到不一样的项目上。因为多个其余的系统须要项目的信息，因此 咱们就建立了项目服务。这个服务将项目以RESTful资源的形式暴露出来，外部系统能够 把它们的集成点迁移到这个新的、易用的服务上来，而这个项目服务仅仅是隐藏了底层的 集成细节而已。如图4-12所示。

图4-12:使用外观服务来隐藏底层的CRM

 

在本书写做时，这项工做还在继续进行中。持续识别出其余CRM管理的领域概念，而后 在其之上封装出外观。等到迁移时机到来时，能够查看每个外观来决定，是本身编写软 件仍是使用一些现成的方式来完成这些工做。

 

4.15.5绞杀者模式

 

你一般难以彻底控制遗留系统和COTS平台，因此当你使用它们时要考虑若是须要移除或 者绕过它们的话，应该如何操做。一个有用的模式叫做绞杀者模式（Strangler Application Pattern,  http://martinfowler.com/bliki/StranglerApplication.html)0 与在 CMS 系统前面套一层 本身的代码很是相似，绞杀者能够捕获并拦截对老系统的调用。这里你就能够决定，是把 这些调用路由到现存的遗留代码中仍是导向新写的代码中。这种方式能够帮助咱们逐步对老系统进行替换，从而避免影响过大的重写。

 

在微服务的上下文中，一般不会使用单一的单块应用来拦截全部对已有遗留系统的调用， 相反你可能会使用一系列的微服务来实施这些拦截。在这种状况下，捕获并重定向这些原 始调用可能会变得更加复杂，可能须要使用一个代理来为你作这些事情。

 

4.16 小结

 

前面了解了不少不一样的集成选择，我也谈了什么样的选择可以最大程度地保证微服务之间 的低耦合：

 

•不管如何避免数据库集成

 

•理解REST和RPC之间的取舍，但老是使用REST做为请求/响应模式的起点 

•相比编排，优先选择协同

 

•避免破坏性修改、理解Postel法则、使用容错性读取器

 •将用户界面视为一个组合层

 

这里覆盖了不少内容，每一个话题都不可能讲得很是深刻。但起码你知道有哪些点须要学 习，以及正确的方向是什么，这对你的进一步学习颇有帮助。

 

咱们也花了一些时间来研究如何应对那些不彻底受控的系统，好比COTS产品。细想一下 你会发现，这些原则也很容易应用到咱们本身编写的软件中。

 

这里列出的一些方法，对遗留系统来讲一样好用，可是若是我想要把一个大系统分解成为 可重用的小系统，应该怎么作呢？下一章会着重讲解这个问题。