Java开发大型互联网-持之以恒的微服务架构九大特性

引言

微服务架构是一项在云中部署应用和服务的新技术。大部分围绕微服务的争论都集中在容器或其他技术是否能很好的实施微服务，而红帽说API应该是重点。

微服务可以在“自己的程序”中运行，并通过“轻量级设备与HTTP型API进行沟通”。关键在于该服务可以在自己的程序中运行。通过这一点我们就可以将服务公开与微服务架构（在现有系统中分布一个API）区分开来。在服务公开中，许多服务都可以被内部独立进程所限制。如果其中任何一个服务需要增加某种功能，那么就必须缩小进程范围。在微服务架构中，只需要在特定的某种服务中增加所需功能，而不影响整体进程。

微服务架构九大特性

特性一：“组件化”与“多服务”

自我们从事软件行业以来，发现大家都有“把组件插在一起来构建系统”的愿望，就像在物理世界中所看到的那样。在过去几十年中，我们已经看到，在公共软件库方面已经取得了相当大的进展，这些软件库是大多数编程语言平台的组成部分。

当谈到组件时，会碰到一个有关定义的难题，即什么是组件？我们的定义是：一个组件就是一个可以独立更换和升级的软件单元。

微服务架构也会使用软件库，但其将自身软件进行组件化的主要方法是将软件分解为诸多服务。我们将软件库(libraries)定义为这样的组件，即它能被链接到一段程序，且能通过内存中的函数来进行调用。然而，服务(services)是进程外的组件，它们通过诸如web service请求或远程过程调用这样的机制来进行通信（这不同于许多面向对象的程序中的service object概念[3]）。

以使用服务（而不是以软件库）的方式来实现组件化的一个主要原因是，服务可被独立部署。如果一个应用系统[4]由在单个进程中的多个软件库所组成，那么对任一组件做一处修改，都不得不重新部署整个应用系统。但是如果该应用系统被分解为多个服务，那么对于一个服务的多处修改，仅需要重新部署这一个服务。当然这也不是绝对的，一些变更服务接口的修改会导致多个服务之间的协同修改。但是一个良好的微服务架构的目的，是通过内聚的服务边界和服务协议方面的演进机制，来将这样的修改变得最小化。

以服务的方式来实现组件化的另一个结果，是能获得更加显式的（explicit）组件接口。大多数编程语言并没有一个良好的机制来定义显式的发布接口。通常情况下，这样的接口仅仅是文档声明和团队纪律，来避免客户端破坏组件的封装，从而导致组件间出现过度紧密的耦合。通过使用显式的远程调用机制，服务能更容易地规避这种情况。

如此使用服务，也会有不足之处。比起进程内调用，远程调用更加昂贵。所以远程调用API接口必须是粗粒度的，而这往往更加难以使用。如果需要修改组件间的职责分配，那么当跨越进程边界时，这种组件行为的改动会更加难以实现。

近似地，我们可以把一个个服务映射为一个个运行时的进程，但这仅仅是一个近似。一个服务可能包括总是在一起被开发和部署的多个进程，比如一个应用系统的进程和仅被该服务使用的数据库。

特性二：围绕“业务功能”组织团队

当在寻求将一个大型应用系统分解成几部分时，公司管理层往往会聚焦在技术层面上，这就意味着要组建用户界面团队、服务器端团队和数据库团队。当团队沿着这些技术线分开后，即使要实现软件中一个简单的变更，也会发生跨团队的项目时延和预算审批。在这种情况下，聪明的团队会进行局部优化，“两害相权取其轻”，来直接把代码逻辑塞到他们能访问到的任意应用系统中。换句话说，这种情况会导致代码逻辑散布在系统各处。这就是康威定律[5]的鲜活实例。

图2：康威定律在起作用

微服务使用不同的方法来分解系统，即根据业务功能（business capability）来将系统分解为若干服务。这些服务针对该业务领域提供多层次、广泛的软件实现，包括用户界面、持久性存储以及任何对外的协作性操作。因此，团队是跨职能的，它拥有软件开发所需的全方位的技能：用户体验、数据库和项目管理。

图3：被团队边界所强化的服务边界

跨职能团队负责构建和运维每个产品，而每个产品被拆分为多个独立的服务，彼此通过一个消息总线来通信。

特性三：“做产品”而不是“做项目”

我们所看的大部分应用系统的开发工作都使用项目模型：目标是交付某一块软件，之后就认为完工了。一旦完工后，软件就被移交给维护团队，接着那个构建该软件的项目团队就会被解散。

微服务的支持者们倾向于避免使用上述模型，而宁愿采纳“一个团队在一个产品的整个生命周期中都应该保持对其拥有”的理念。通常认为这一点源自亚马逊的“谁构建，谁运行”的理念，即一个开发团队对一个在生产环境下运行的软件负全责。这会使开发人员每天都关注软件是如何在生产环境下运行的，并且增进他们与用户的联系，因为他们必须承担某些支持工作。

这样的“产品”理念，是与业务功能的联动绑定在一起的。它不会将软件看作是一个待完成的功能集合，而是认为存在这样一个持续的关系，即软件如何能助其客户来持续增进业务功能。

当然，单块应用系统的开发工作也可以遵循上述“产品”理念，但是更细粒度的服务，能让服务的开发者与其用户之间的个人关系的创建变得更加容易。

特性四：“智能端点”与“傻瓜管道”

当在不同的进程之间构建各种通信结构时，我们已经看到许多产品和方法，来强调将大量的智能特性纳入通信机制本身。其中一个典型例子，就是“企业服务总线”(Enterprise Service Bus, ESB)。ESB产品经常包括高度智能的设施，来进行消息的路由、编制(choreography)、转换，并应用业务规则。

微服务社区主张采用另一种做法：智能端点(smart endpoints)和傻瓜管道(dumb pipes)。使用微服务所构建的各个应用的目标，都是尽可能地实现“高内聚和低耦合”——他们拥有自己的领域逻辑，并且更像是经典Unix的“过滤器”(filter)那样来工作——即接收一个请求，酌情对其应用业务逻辑，并产生一个响应。这些应用通过使用一些简单的REST风格的协议来进行编制，而不去使用诸如下面这些复杂的协议，即"WS-编制"(WS-Choreography)、BPEL或通过位于中心的工具来进行编排(orchestration)。

微服务最常用的两种协议是：带有资源API的HTTP“请求－响应”协议，和轻量级的消息发送协议[6]。对于前一种协议的最佳表述是：

成为Web，而不是躲着Web (Be of the web, not behind the web)——Ian Robinson

这些微服务团队在开发中，使用在构建万维网(world wide web)时所使用的原则和协议（并且在很大程度上，这些原则和协议也是在构建Unix系统时所使用的）。那些被使用过的HTTP资源，通常能被开发或运维人员轻易地缓存起来。

最常用的第二种协议，是通过一个轻量级的消息总线来进行消息发送。此时所选择的基础设施，通常是“傻瓜”(dumb)型的(仅仅像消息路由器所做的事情那样傻瓜)——像RabbitMQ或ZeroMQ那样的简单实现，即除了提供可靠的异步机制(fabric)以外不做其他任何事情——智能功能存在于那些生产和消费诸多消息的各个端点中，即存在于各个服务中。

在一个单块系统中，各个组件在同一个进程中运行。它们相互之间的通信，要么通过方法调用，要么通过函数调用来进行。将一个单块系统改造为若干微服务的最大问题，在于对通信模式的改变。仅仅将内存中的方法调用转换为RPC调用这样天真的做法，会导致微服务之间产生繁琐的通信，使得系统表现变糟。取而代之的是，需要用更粗粒度的协议来替代细粒度的服务间通信。

特性五：“去中心化”的治理技术

使用中心化的方式来对开发进行治理，其中一个后果，就是趋向于在单一技术平台上制定标准。经验表明，这种做法会带来局限性——不是每一个问题都是钉子，不是每一个方案都是锤子。我们更喜欢根据工作的不同来选用合理的工具。尽管那些单块应用系统能在一定程度上利用不同的编程语言，但是这并不常见。

如果能将单块应用的那些组件拆分成多个服务，那么在构建每个服务时，就可以有选择不同技术栈的机会。想要使用Node.js来搞出一个简单的报表页面？尽管去搞。想用C++来做一个特别出彩的近乎实时的组件？没有问题。想要换一种不同风格的数据库，来更好地适应一个组件的读取数据的行为？可以重建。

特性六：“去中心化”地管理数据

去中心化地管理数据，其表现形式多种多样。从最抽象的层面看，这意味着各个系统对客观世界所构建的概念模型各不相同。当在一个大型的企业中进行系统集成时，这是一个常见的问题。比如对于“客户”这个概念，从销售人员的视角看，就与从支持人员的视角看有所不同。从销售人员的视角所看到的一些被称之为“客户”的事物，或许在支持人员的视角中根本找不到。而那些在两个视角中都能看到的事物，或许各自具有不同的属性。更糟糕的是，那些在两个视角中具有相同属性的事物，或许在语义上有微妙的不同。

上述问题在不同的应用程序之间经常出现，同时也会出现在这些应用程序内部，特别是当一个应用程序被分成不同组件时就会出现。思考这类问题的一个有效方法，就是使用领域驱动设计（Domain-Driven Design, DDD）中的“限界上下文”（Bounded Context）的概念。DDD将一个复杂的领域划分为多个限界上下文，并且将其相互之间的关系用图画出来。这一划分过程对于单块和微服务架构两者都是有用的，而且就像前面有关“业务功能”一节中所讨论的那样，在服务和各个限界上下文之间所存在的自然的联动关系，有助于澄清和强化这种划分。

特性七：“基础设施”自动化

基础设施自动化技术在过去几年里已经得到长足的发展。云的演进，特别是AWS的发展，已经降低了构建、部署和运维微服务的操作复杂性。

许多使用微服务构建的产品和系统，正在被这样的团队所构建，即他们都具备极其丰富的“持续交付”和其前身“持续集成”的经验。用这种方法构建软件的各个团队，广泛采用了基础设施的自动化技术。如下图的构建流水线所示：

图5：基本的构建流水线

由于本文并不是一篇有关持续交付的文章，所以下面仅提请大家注意两个持续交付的关键特点。为了尽可能地获得对正在运行的软件的信心，需要运行大量的自动化测试。让可工作的软件达到“晋级”(Promotion)状态、从而“推上”流水线，就意味着可以在每一个新的环境中，对软件进行自动化部署。

一个单块应用程序，能够相当愉快地在上述各个环境中，被构建、测试和推送。其结果是，一旦在下述工作中进行了投入，即针对一个单块系统将其通往生产环境的通道进行自动化，那么部署更多的应用系统似乎就不再可怕。记住，持续交付的目的之一，是让“部署”工作变得“无聊”。所以不管是一个还是三个应用系统，只要部署工作依旧很“无聊”，那么就没什么可担心的了

。

我们所看到的各个团队在广泛使用基础设施自动化实践的另一个领域，是在生产环境中管理各个微服务。与前面我们对比单块系统和微服务所说的正相反，只要部署工作很无聊，那么在这一点上单块系统和微服务就没什么区别。然而，两者在运维领域的情况却截然不同。

图6：两者的模块部署经常会有差异

特性八：“容错”设计

使用各个微服务来替代组件，其结果是各个应用程序需要被设计的能够容忍这些服务所出现的故障。如果服务提供方不可用，那么任何对该服务的调用都会出现故障。客户端要尽可能优雅地应对这种情况。与一个单块设计相比，这是一个劣势。因为在处理这种情况时会引入额外的复杂性。为此，各个微服务团队在不断地反思：这些服务故障是如何影响用户体验的。Netflix公司所研发的开源测试工具Simian Army，能够诱导服务发生故障，甚至能诱导一个数据中心在工作日发生故障，来测试该应用的弹性和监控能力。

这种在生产环境中所进行的自动化测试，足以让大多数运维组织兴奋得浑身颤栗，就像即将迎来一周的长假那样。这并不是说单块架构风格不能构建先进的监控系统——只是根据我们的经验，这在单块系统中并不常见罢了。

特性九：“演进式”设计

那些微服务的从业者们，通常具有演进式设计的背景，而且通常将服务的分解，视作一个额外的工具，来让应用开发人员能够控制应用系统中的变化，而无须减少变化的发生。控制变化并不一定意味着要减少变化——在正确的态度和工具的帮助下，软件中的变化也可以发生得频繁、快速且得到良好的控制。

每当要试图将软件系统分解为各个组件时，就会面临这样的决策，即如何进行切分——我们决定切分应用系统时应该遵循的原则是什么？一个组件的关键属性，是具有独立更换和升级的特点[13]——这意味着，需要寻找这些点，即想象着能否在其中一个点上重写该组件，而无须影响该组件的其他合作组件。事实上，许多做微服务的团队会更进一步，他们明确地预期许多服务将来会报废，而不是守着这些服务做长期演进。

英国卫报网站是一个好例子。原先该网站是一个以单块系统的方式来设计和构建的应用系统，然而它已经开始向微服务方向进行演进了。原先的单块系统依旧是该网站的核心，但是在添加新特性时他们愿意以构建一些微服务的方式来进行添加，而这些微服务会去调用原先那个单块系统的API。当开发那些本身就带有临时性特点的新特性时，这种方法就特别方便，例如开发报道一个体育赛事的专门页面。当使用一些快速的开发语言时，这样的网站页面就能被快速地整合起来。而一旦赛事结束，这样页面就可以被删除。在一个金融机构中，我们已经看到了一些相似的做法，即针对一个市场机会，一些新的服务可以被添加进来。然后在几个月甚至几周之后，这些新服务就作废了。

这种强调“可更换性”的特点，是模块化设计一般性原则的一个特例，通过“变化模式”(pattern of change)[14]来驱动模块化的实现。大家都愿意将那些能在同时发生变化的东西，放到同一个模块中。系统中那些很少发生变化的部分，应该被放到不同的服务中，以区别于那些正在经历大量变动(churn)的部分。当发现两个服务需要被同时、反复变更，就意味着它们两个需要被合并。

把一个个组件放入一个个服务中，提高了软件发布精细化的程度。对于一个单块系统，任何变化都需要做一次整个应用系统的全量构建和部署。然而，对于一个个微服务来说，只需要重新部署修改过的那些服务就够了。这能简化并加快发布过程。但缺点是：必须要考虑当一个服务发生变化时，依赖它并对其进行消费的其他服务将无法工作。传统的集成方法是使用版本化来解决这个问题。但在微服务世界中，大家更喜欢将版本化作为最后万不得已的手段来使用。我们可以通过下述方法来避免许多版本化的工作，即把各个服务设计得尽量能够容错，来应对其所依赖的服务所发生的变化。

总结

以 上就是我对Java开发大型互联网-持之以恒的微服务架构九大特性  问题及其优化总结，分享给大家，觉得收获的话可以点个关注收藏转发一波喔，谢谢大佬们支持！

最后，每一位读到这里的网友，感谢你们能耐心地看完。希望在成为一名更优秀的Java程序员的道路上，我们可以一起学习、一起进步！都能赢取白富美，走向架构师的人生巅峰!

想了解学习Java方面的技术内容以及Java技术视频的内容可加群：722040762 验证码：（666 必过）欢迎大家的加入哟！