关键点

微服务架构MSA并不是一个全新的概念，它旨在通过使用现代技术的优点来正确地实现SOA。

微服务只能解决整体问题的一小部分——架构师们需要将微服务架构作为一种架构实践，并实现它以满足企业级应用要求。

“微”不仅仅只是关注大小，它主要是关注范围。

整合是微服务架构的一个关键方面，在适用时，它可以作为微整合来实施。

迭代式的方法可以帮助组织从其当前状态转换到一个完整的微服务架构。

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

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

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

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

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

解决实现的挑战

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

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

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

内部架构的范围确定和设计

值得注意的是，内部架构需要设计得比较简单，因此它才可以很容易地独立部署，或者单独废弃。一旦出现微服务失败或有更好的服务出现，可废弃性是必需的。无论是这两种情况下的哪一种，都需要可以很容易地废弃相应的微服务。微服务也需要获得部署架构和运行环境的强有力支持，微服务要在这样的运行环境中被构建、部署和执行。因此，它需要足够简单，这样才能独立部署。理想的做法是发布一个相同服务的新版本，加入对缺陷的修复，包括新的功能或者对现有功能的改进，并去除掉废弃的功能。

微服务架构建立的基础框架决定着对一个微服务架构的内部架构的关键需求。吞吐量、延迟和低资源使用率（内存和CPU）等都是需要考虑的关键需求。一个好的微服务框架通常会建立在轻量级、运行速度快和现代编程模型的基础之上，比如注释元配置，它与核心业务逻辑相独立。此外，它应该有能力来保障微服务的安全，满足必要的行业领先的安全标准，也应同时提供一些指标来监测微服务的行为。

与外部架构相比，内部架构中每一个微服务的实现都比较简单。在搜寻和设计内部架构时，一个好的服务设计要考虑到以下六个因素：

首先，微服务应该有单一的目的和单一的责任，并且服务本身应该作为一个独立的部署单元，可以在生产部署时创建多个实例。

其次，微服务应该有这样的能力，那就是可以采用一个最适合它要发布的功能的架构，并且此架构能够使用适当的技术。

第三，一旦单体服务被细分为微服务，每一项微服务或每套微服务就应该有可以通过API提供服务的能力。然而，在内部实现中，该服务可以采用任何合适的技术，实现业务需求，实现各自的业务能力。为此，企业可能要考虑像Swagger那样的东西来定义API规范或特定微服务的API定义，并且微服务能利用这个作为互动的点。这在微服务开发中被称为以API为先的方法。

第四，要部署的内容也可能有不同，比如捆绑在基于Hypervisor的镜像的独立的可部署单元，或者是容器镜像，这通常是更受欢迎的选择。

第五，企业需要利用分析来细化微服务，同时一旦服务失败要提供恢复手段。为此，企业要整合使用度量指标和监控来支持微服务的演进方法。

第六，即使微服务范式本身可以让企业的微服务有多种实现或多语言实现，对最佳实践和标准的使用对于保持一致性是非常必要的，同时要确保解决方案遵循一般的企业架构原则。这并不是说，多语言的机会就被完全否决了，而是说它们在使用时需要被监管。

用“外部架构”来解决平台能力

一旦内部架构已经建立，架构师就需要关注组成他们微服务架构的外部架构的功能。外部架构的一个关键组成部分是引入企业服务总线（ESB）或类似的中介引擎，它们将会帮忙把历史数据和服务与微服务架构连接起来。中介层也将使企业可以维护自己的标准，同时让别人可以在相应的生态系统里管理他们自己的。

使用服务注册中心可以支持依赖管理、影响分析、微服务和API的发现功能。这也可以把服务和API的组合流水线化，并把微服务连线到服务经纪人或枢纽。任何微服务架构都应该支持创建RESTful API，这将有助于在企业开发应用软件时定制资源模型和应用逻辑。

先设计API，再实现微服务，然后通过API将它提供出去，要注意提供出去的是API而不是微服务。要坚持这样的原则。各家企业都想要解决的另一个共同需求是微服务的安全问题。在一个典型的单体应用程序中，企业将使用底层存储库或用户存储区来生成来自旧架构的安全层所需要的信息。在微服务架构中，企业可以利用在业界广泛采用的API安全标准，比如OAuth2和OpenID Connect等，去实现对边缘模块的安全层，包括微服务架构中的API。

在所有这些能力中，最重要的也是真正有助于解决微服务架构复杂性的是使用企业级的底层平台，它可以提供丰富的功能来管理可扩展性、可用性和性能。这是因为把一个单体应用分解成微服务并不意味着一个简化了的环境或服务。可以肯定的是在应用层面，企业本质上是在处理几个微服务，这远比一个单一的复杂的应用更简单。然而，作为一个整体的构建却是相当地艰巨。

事实上，微服务架构的复杂度可能更大，因为我们当需要考虑其他方面时，比如向一个进程发起一次单向调用这不算复杂，但微服务之间是需要相互调用的。这在本质上意味着，系统的复杂性已经变成了所谓的“外部架构”，这通常由API网关、服务路由、发现、消息通道和依赖管理等组成。

因为内部架构现在已经极其简单，它只包含用来构建一个微服务架构的基础和运行时，架构师将会发现现在微服务架构已经有了一个干净的服务层。我们需要更多地关注外部架构，以解决大家所共同面临的复杂性。如下图所示，有一些常见的切实的场景需要解决：

外部架构将需要一个API网关，以帮助它对内对外提供业务API的能力。通常，大家会使用API管理平台来管理这方面的外部架构。这对于那些正在构建Web应用程序、移动应用程序和物联网解决方案等的用户来说，把这些基于微服务架构的服务能力提供给他们是非常必要的。

一旦微服务到位，就会出现某种形式的服务路由，通过API发过来的业务请求将被路由到相关服务集群或服务。在微服务内部，会有以分担负载为目的的多个实例。因此，有必要进行某种形式的负载均衡。

此外，微服务之间也有相关性。例如，如果微服务A对微服务B有依赖，它将在运行时调用微服务B。服务注册中心可以让微服务发现后台服务节点，所以它可以解决这个需求。服务注册中心还将管理API和服务依赖关系，以及其他资产，包括策略。

接下来，微服务架构外部架构需要一定的信息传递渠道，这基本上形成了一层，允许微服务内部的交互，并且该层还把微服务架构连接到旧的系统。此外，这一层也有助于建立微服务之间通信（微整合）通道，并且这样的通道应该是轻量级的协议，比如HTTP、MQTT等等。

当微服务之间相互通信时，需要有某种形式的身份验证和授权。使用单体的应用程序时这是不必要的，因为有一个直接的过程调用。相比之下使用微服务时，这些就转化成了网络调用。最后，诊断和监控都是需要考虑的关键方面，以找出由每个微服务处理的请求类型。这将有助于企业扩展单个微服务的规模。

回顾微服务架构场景

为了全面正确地看待事情，我们分析一些实际场景，这些场景展示了微服务架构的内部和外部架构如何一起运作。我们将假设组织已经使用微软Windows Communication Foundation或Java JEE/J2EE服务框架实现了她的服务，并且开发人员还在写新服务代码，使用的是应用了微服务架构原则的微服务框架。

在这种情况下，提供数据和业务能力的现有服务不能被忽视。因此，新的微服务将需要与现有服务平台之间相互通信。在大多数情况下，这些现有的服务将使用框架所坚持的固有标准。例如，旧的服务可能使用服务绑定，比如HTTP上的SOAP、Java Message Service （JMS）或IBM MQ等，并使用Kerberos或WS-Security进行保护。在这个例子中，消息渠道也将在协议转换、信息转换、从旧架构通向新的微服务架构的安全过渡中起重要的作用。

另一个组织需要考虑的方面是在业务增长方面可能造成的对其可扩展性的影响，由于单体应用在这方面是有很明显的局限性的，而微服务架构是可以横向扩展的。在这些明显的限制中，还有可能的错误，因为在一个单片环境里测试新的功能非常繁琐，会导致延迟实现这些变更，成为满足快速提交需求的障碍。另一个挑战将是在所有者缺失的情况下支撑这个单体的代码库，在微服务的情况下，个人或单个功能是可以自己管理的，这些可以在不影响其他功能的情况下根据需要迅速扩展。

总之，虽然微服务对于组织有显著的好处，以逐步淘汰或迭代的方式向前推进微服务架构以确保平稳过渡，这可能是最好的办法。能使微服务架构成为被优先选择的以服务为向导的方案，其关键是明确所有权，以及它可以将故障隔离，从而使这些所有者可以把他们的领域内的服务实现得更加稳定和高效。