微服务结构说明【翻译】

微服务是服务对象结构的一种特殊的设计模式。它是一个开源的方法论，在这个服务结构的类型中，所有的处理过程是通过极小粒度之间的通讯实现一个大的系统和服务。为了方便理解，这篇文章使用一些相关的事例讨论微服务的基本功能。

 

观众

这篇文章准备帮助初学者了解微服务结构的基本概念。

 

预备知识

这是一篇基础的文章，为了充分了解它，需要了解计算机相关基础知识和服务对象结构知识

微服务结构介绍

微服务是一个基于服务应用开发方法论。在这个技术方法论中，大的应用将被拆分成小的独立的服务单元。微服务是通过将整个应用拆分成互相连通的服务集合去实现处理服务对象结构，每一个服务将仅仅对一个业务进行服务。

微服务行为的概念

在一个服务对象结构中，整个软件包将被拆分成小的，互联的商业单元。这些小的业务单元使用不同的协议互相通信最终实现一个成功的业务到客户端。现在的问题是，微服务结构和SOA有什么不同？换句话说，SOA是一个设计模式而微服务是为了实现SAO的一个实现方法论，或者我们可以说微服务是一个特殊的SOA.

 

下面一些规则我们是开发一个微服务对象应用需要记住的。

独立性---每一个微服务是可以独立部署的

耦合性---所有的微服务应该是互相松耦合的，比如改变其中一个而不影响另外一个。

业务目标---应该应用的每一个服务单元应该是细小的并且可以单独实现一个业务目的。

 

让我们去考虑一个网上商城事例入口去深度理解微服务。现在让我们打碎整个电子商务入口到小的业务单元，比如:用户管理，订单管理，签到，支付管理，交付管理等等。一个成功的订单需求需要在一个特定的时间范围内经过所有这些模块进行处理。下面经过处理的不同业务单元的图片是和一个电子商务系统相关。

 

这些每一个业务模块应该有它自己的业务逻辑和利益相关者。对于一些特别的需求它们也可以与第三方供应软件通讯，或者是互相交互。例如，订单管理可以与用户管理交互去获取用户信息。

现在，认为你用前面提到的这些业务单元运行一个在线购物商城，你需要进行一些企业级的不同层级的考虑，比如：前端，后端，数据层等等，如果你的应用没有拆分并且完全开发在一个单独的war文件中，它们将被认为是一个典型的整体应用。依据IBM，一个典型的整体应用应该持有如下内在的模块结构，这里仅仅有一个端点或者应用将负责控制所有用户的请求。

 

在上面的图片中，你能看到不同的模块，比如:存储不同用户的数据库和业务数据。在前端，我们有不同的设备，这里我们通常渲染用户或者业务数据给用户。在中间，我们有一个可部署的ear或者war包，它能接受用户端请求，用资源的帮助处理请求和渲染它给到用户。除非以上事例业务发生改变，否则这个将是一个很好的实例。

 

考虑如下几种场景，这里你不得不因为业务需求调整你的应用。

在“搜索”模块业务单元需要一些改变。接着，你需要调整整个搜索处理并且重新部署你的应用。在这个情况下，你将不得不重新部署其他没有任何改变的业务单元。

 

现在，你的业务单元比如“结账”模块包括钱包选项需要一些改变。你将不得不改变你的“结账”模块并且重新发布相同的到服务器中。注意，你重新发布了你软件包中的其他模块，而这些模块我们并没有做任何改变。这里引入了服务对象结构更特别的微服务结构。我们能用一种方式开发我们的整个应用，整个应用的每一个模块将作为一个独立的单元运行，有着担负单一的独立业务任务能力。

比如如下实例。

比如以上结果，我们没有创建任何端到端连接的服务所说的文件。相反，我们拆分软件不同的部分，并将它们暴露作为一个服务。软件的任何一个部分使用各自的服务进行互相通信。那么微服务在现代web应用中怎么扮演一个伟大的角色。

 

让我们比较下线上微服务中的购物车事例。我们能分解我们的购物车为不同的模块，例如：“搜索”，“筛选”，“结账”，“车”，“推荐”等等，如果我们想构建一个购物车入口，接着我们不得不构建上面提到的模块，在这种方式中，它们彼此互相连接给你一个24×7的购物体验。

优势和劣势

下面一些点是使用微服务代替整个应用的优势。

粒度小-----微服务是一个继承SOA的设计模式。建议您尽可能多地保留您的服务。基本上，一个服务不应该允许大于一个以上的业务请求，因此它应尽可能的小并且比起其他整个应用应更容易维护。

聚焦的----前面提到的，每一个微服务被设计成仅仅承担一个业务任务。在我们设计微服务期间，架构师应该关注服务的聚焦点，那些是可以交付使用的。通过定义，微服务性质上应该是完全堆叠的并且可以单独作为一个业务属性进行提交。

自治的-----每一个微服务在整个应用中应该是一个自治的业务单元。因此，应用变得更松散耦合，它将帮助降低维护费用。

技术多项性---微服务在一个业务单元中支持不同的技术进行互相通信，帮助开发中在正确的地方使用正确的技术。通过实现一个多项性的系统，一个能获取最大安全，快速并且一个可伸缩的系统。

恢复力----是一个软件单元隔离性的属性。微服务在构建方法论中是遵循高级别的恢复力，因此一个单元异常而不影响整个业务。恢复力是实现高扩展并且少耦合系统的另一个属性。

易发布---整个系统被拆分成不同小的单元块，每个主键应该具备完全堆叠的特性。它们能在任何环境快速少时的发布，不像同种性质的其他整个应用那么复杂。

 

下面一些点是微服务结构的劣势。

劣势

分布式系统---由于技术的多项性，不同技术被使用在微服务不同的部分。这么大的多项性软件需要一大群技术熟练的专业人员。因此，分布式和多项性标准作为使用微服务标准的劣势。

费用---微服务是昂贵的，你将不得不对不同的业务任务保持不同的服务空间。

企业准备---微服务结构是被认为是不同技术的集合体，而且技术每天都在更新。因此要使微服务应用程序企业准备好与传统的软件开发模型进行比较是相当困难的

SOA之上的微服务

注意：文章到这里还没有完，由于篇幅限制，完整内容请到hongfu951博客上查看

完整内容URL地址：微服务结构说明【翻译】

欢迎访问:www.hongfu951.com博客，查看更多文章