处理微服务架构的内部架构和外部架构

作者 Asanka Abeysinghe 译者 足下

今天的企业里内容范围非常广，包括服务、传统应用程序和数据等等，这由一系列的消费渠道为首，包括桌面、网站和移动应用等。但是，通常情况下，由于没有一个被以适当的方式创建和系统化地管理的集成层，会出现断层，这些消费渠道需要有这样的集成层来使能业务功能。大多数企业正在通过面向服务的架构（Service-Oriented aArchitecture, SOA）来应对这一挑战。在面向服务的架构中，应用程序组件通过网络上的通信协议向其他组件提供松散耦合的服务。最终，它的意图是让微服务架构可以更灵活和更容易地扩展。虽然没有充分地准备好采用微服务架构，但是这些组织正在规划架构并实现企业应用和服务平台，使他们可以逐步走向微服务架构。

事实上，Gartner预测到2017年为止，超过20%的大型机构将会部署完整的微服务，以提高灵活性和可扩展性，事实上她们已经这样做了。微服务架构正日益成为有效地提交新功能的重要途径。它可以解决伴随着创建新服务的同时带来的复杂难题，结合传统应用程序和数据库，并开发Web应用程序、移动应用程序或任何基于消费者的应用。

现在，企业们正在朝着SOA发展，并且在SOA的范围里张开臂膀迎接微服务架构的概念。很有可能，最大的吸引力在于由这些微服务提供的组件化和单一功能，使得迅速部署组件以及按需扩展变得可能。它已经不再只是一个新的概念。

比如在2011年，有一个医疗服务平台启动了一个新的策略，就是每当它写了一个新的服务时，它就会相应地为它配备一台新的应用服务器，以支持服务部署。因此，这是一个来自于DevOps的实践，它为服务之间创造了一种依赖较少的环境，并确保在进行某些维护操作的时候对其他系统影响可以降到最小。其结果是，这些服务运行在超过了80台服务器之上。事实上这是非常基本的，因为那时不像现在这样有适当的DevOps工具，相反，他们使用Shell脚本和Maven类型的工具来构建服务器。

然而微服务是非常重要的，它只是一个大格局的一个小方面。很明显，一个组织不可能仅仅因为使用了微服务就能得到微服务的全部好处。在设计微服务的时候，采用微服务架构以及最佳实践的做法是营造一个鼓励创新的环境，并实现业务能力的快速提交的关键所在。这就是真正的附加价值。

解决实现的挑战

在构建你自己的微服务架构时，大家普遍接受的实践是专注于你如何打磨出单一功能的服务，而不是服务的规模。内部架构通常只能解决微服务自己的实现。外部架构包括必需的平台能力，在开发和部署你的微服务时，会需要这些平台能力来确保可连接性、灵活性和可扩展性。为此，在制作你内部和外部的微服务架构的时候，企业中间件起着关键的作用。

首先，中间件技术应该兼容是对DevOps友好的，它包含高性能的功能，并且支持关键服务标准。此外，它必须支持一些设计原则，比如迭代架构并且易于插拔，这反过来将提供快速的应用程序开发与持续发布。最重要的是，一个全面的数据分析层对于设计失败的支持是至关重要的。

在实施微服务架构时，企业常犯的最大错误往往是完全抛弃了已经确立的SOA方法，并且用微服务背后的理论来替换它们。这样就会导致架构不完整，并且引入了冗余。聪明一些的做法是把一个微服务架构当成一个分层的系统，它包括类似企业服务总线（Enterprise Service Bus, ESB）的功能来处理所有的与整合相关的功能。这也将作为一个中间层，使变化可以发生在这个层面上，这样它可以应用到所有相关的微服务。换句话说，ESB或类似的中介引擎通过提供所需的连接性去将历史数据和服务整合到微服务，实现逐步向微服务架构推进。先发布微服务，然后再通过API把它提供出去，这种方法对于整合一些基本规则来说也很重要。