微服务架构： 什么是微服务, 是什么时候和怎么使用微服务
微服务架构现在已经广泛使用，看看什么是微服务，简要概述一下什么时候和怎么样使用它们，以及相对于单体架构的优势。
介绍
现在，微服务架构模式得到了广泛关注，并且已经成为趋势。如果不清楚可以来看看谷歌搜索趋势。
可以看到从2014年开始，人们对这个词的兴趣大增，随着时间的推移，这种趋势还在不断增加。
这种对微服务炒作正处于顶峰。即使是在当前炒作的高峰期，也值得研究微服务架构风格。我相信这肯定有一定的风险，花时间去理解它是很好的。
有一些微服务架构优越性支撑起这种炒作。像Netflix、亚马逊(Amazon)和其他一些大公司已经在使用微服务架构来扩展和简化服务的持续交付方式。
微服务架构设计并没有被忽视，这个架构框架是Docker、CoreOS、基础设施(云计算)等新兴公司的核心卖点。
这些新产品正在缓解基于微服务架构的应用程序的开发和部署工作。
Docker是一种开放源码的容器技术，它使我们能够在单个Linux操作系统上部署多个独立的独立应用程序(或服务)，因为它们在自己的操作系统环境中运行。它在过去一年里经历了巨大的增长，其主要赞助商Docker Inc.的估值已超过10亿美元，同时也获得了投资。所以我认为有足够的理由对微服务架构框架进行全面的分析。
在本文中，我们将详细讨论微服务架构风格。
我们将试着回答以下问题:
- 它是什么?
- 什么时候应该使用?
- 我们应该如何使用它?
它（微服务）是什么?
当我们将其与单体架构应用程序设计进行比较时，微服务架构更有意义。
在单体架构设计中，我们创建了一个大且完整的的应用程序，所有模块紧密耦合在一个可执行文件中，通常部署在web或应用服务器上。
一个典型的整体架构应用程序是这样的：
这种架构设计有一些缺点，而这些缺点则成为微服务体系结构的优势：
由于组件之间的紧密耦合，由于组件之间的紧密耦合，很难实现简单和频繁的发布。发布计划需要花费来自不同人员（开发、测试、配置管理、运维等）的大量时间。为了确保应用程序不应该因为新发布的特性而中断，经常会减少或取消一些发布。
持续交付的问题——如果应用程序很小，我们可能不会注意到这个问题。在更大的单体架构应用程序的情况下，部署时间可能会令人沮丧地漫长和缓慢。如果应用程序的单个更改需要重新部署整个应用程序，那么这可能会成为频繁部署的障碍，从而阻碍持续交付。而如果你正在提供一个移动应用程序，用户总是期待最新的新功能，这可能是会是一个严重的问题。
难以管理团队和项目——项目管理在整体应用开发中有自己的挑战。即使是模块化的应用程序在部署和发布方面也有相互依赖关系。计划发布和管理紧密耦合的相互依赖的模块开发需要付出时间和精力。
昂贵的可伸缩性和性能——可以扩展一个单体架构应用程序，但是成本非常高。
缺乏技术多样性——当我们为一个单一的应用程序选择一个技术栈时，我们考虑一个平衡的技术栈，它可以满足我们所有的需求。我们不能采用专门技术来满足特殊需要。
不容易替换组件——在不影响整个体系结构的情况下，用更好的设计或性能来替换任何组件是非常困难的。
定义
简而言之，微服务架构风格定义了一个“安装包”，其中应用程序组件就是自己的独立应用程序。这些独立的应用程序组件使用RMI(远程方法调用)、基于restful的Web服务或推送消息相互通信。
这里给出了一个典型的基于微服务的应用程序设置：
在设计微服务体系结构时，我们应该适当地识别独立的组件/模块。这些组件将是微型应用程序，将单独开发。他们将遵循自己的开发和部署生命周期。
我们正在开发一个学校管理系统。在学校管理系统中，我们有许多重要的组成部分，如学生注册、出勤、费用、评估等。
当我们使用微服务体系结构开发这个应用程序时，我们将独立部署用于学生注册、出勤、费用和其他模块的迷你应用程序。
在一般的设置中，我们可以有一些场景，其中我们需要来自多个组件的数据，以满足单个请求。理想情况下，我们将拥有一个API网关或前端控制器，它将聚合来自这些组件的数据并将其返回。
我们需要进行组件间通信，微服务可以通过REST API或消息传递或RMI(远程方法调用)进行通信。
基于微服务架构的应用程序特点如下：
- 服务独立运行，不依赖其它组件。
- 独立运行的组件根据一些业务功能进行分类。
- 使用做产品的思想代替项目心态。
- 组件使用简单的通信通道，如简单的RESTish协议或轻量级消息传递队列。
- 分散的标准。每个独立组件都可以使用它们的开发和部署专用标准。
- 分散的数据管理，每个组件有自己的数据存储。
- 自动化的基础设施管理。对于独立组件的部署，我们需要依赖自动化的基础设施管理来降低复杂性。
- 应用程序设计考虑到失败。在应用程序中有几个独立的移动部件。如果接收方没有得到响应，则应该优雅地处理它。
- 为获得尽可能最好的分解系统而进行的进化设计，可以在不影响其协作者的情况下进行替换和升级。
微服务架构劣势
每个硬币都有两面，类似的微服务体系结构也有自己的问题。我们已经看到了它的优点，所以我们也可以更仔细地看看它的不足之处。
我们在基于微服务架构的应用程序中发现了一些缺点：
团队通信开销——微服务体系结构降低了团队管理的复杂性，但它不能减少团队沟通的需求。团队需要确保一个团队的服务更新不会破坏另一个团队的团队功能。虽然在单体架构应用中也存在类似问题。
过量的文档开销——每个运行组件应用程序的个体都需要时刻保持更新接口文档。它帮助其他使用该服务的团队。
非均匀应用-我们可以为不同的组件选择不同的技术栈(polygot)。它导致了一个非统一的应用程序设计和架构问题，这样会增加长期的维护成本。
DevOps复杂性——我们需要一个成熟的DevOps团队来处理维护基于微服务的应用程序的复杂性。由于应用程序的几个移动部分，它变得复杂，需要一定程度的专业知识。
增加资源使用—运行这些应用程序的初始投资很高，因为所有独立运行的组件都需要拥有更多内存和CPU的运行时容器。
增加网络通信——独立运行的组件使用网络彼此交互。这种系统需要可靠和快速的网络连接。
编码和解码——当一个组件需要来自另一个组件的数据时，发送方从内部表示中将数据从某种标准中封送，而接收方在使用前将数据以自己的表示方式进行解封。与传统的应用程序架构相比，这显然需要更多的处理。
网络安全——为了避免任何安全漏洞，需要确保服务间的通信。由于多个移动部件，这些应用程序更容易出现安全漏洞。
与单一的应用程序相比，测试此类应用程序的难度肯定要大得多。
生产监控——监控此类应用程序的成本更高。没有合适的工具也是一个需要考虑的问题。
高昂的前期成本——运行多个应用程序将会比单一的应用程序花费更多的成本。
我们上面提到的所有问题都可以通过额外的努力或使用适当的工具来解决。在这里，单体架构应用程序也容易出现一些问题。
在下一节中，我们将讨论如何使用微服务体系架构的用例。我们也试着回答这个问题——什么时候，我们应该如何使用微服务架构?
何时以及如何使用它（微服务架构）?
如果我们尝试搜索谷歌关于微服务，我们可以看到一些关于成功实现它的文章。一些产品和公司实施了它：
Netflix
eBay
亚马逊
其他几家大型和中型科技公司。
在这两种方法中，我们应该为任何产品/项目使用微服务体系结构：
单体架构或开始是单体架构。
微服务架构开始。
从单体架构开始：
所有提到的公司最近都将他们的应用程序从一个庞大的单体架构变成了微型服务体系结构。在开始的时候，他们开始作为单体架构应用程序，他们稳步地移动/聚合到微服务。因此，我们在想，微服务是否更适合非常大和复杂的应用程序。
在下列情况下，我们只应选择单一或第一种方法：
企业还没有准备好对基于微服务的应用程序所产生的前期成本进行投资。
业务无法预见微服务提供的价值。
无法使用合适的人力来构建和运行基于微服务的应用程序。
时间紧迫的软件交付:有时单体架构应用帮助快速进入市场。
当工具和技术的状态是否可用来支持微服务应用程序的顺利部署时。
记住上面的几点将有助于决定何时使用微服务。
尽管很难否认微服务应用程序是我们的理想选择，但我们必须看到这一事实。通常，当单个应用程序成功或需要对规模和性能有重大帮助时，我们可以选择微服务。我们可以从以下两方面选择微服务：
从整体上扩展设计好的模块化组件：通常我们会发现业务人员支持单体架构的第一个设计，认为如果需要，可以很容易地将一个模块化设计的单体应用程序转换成后期的微服务。事实上，他们选择了一个模块化的单体应用程序，以降低他们开发微服务所需的成本。
从头创建microservices应用程序并转换现有的单体应用程序，大多数时间微服务应用程序都是从零开始开发的，因为单体架构应用程序的模块性很差。
从微服务开始构建应用系统：
当我们开始开发应用程序时，我们总是希望保持它们的模块化。每个模块应该有各自不同的职责。我们试图这样做，以减少应用程序的复杂性，以实现扩展和更易维护。
我认为，如果模块化是选择微服务的主要原因，那么为什么这在单体应用程序中是不可能的呢?毕竟，我们也可以把它应用在单一的应用程序中。
我认为答案在于我们开发软件的方式，以及它如何从一个小模块成长为一个非常大的应用系统。在单体架构应用程序中，我们总是倾向于快速地开发事物，因为没有定义的硬边界，并且在快速地滚动开发的同时，我们失去了系统模块化。从长远来看，这些重叠的模块功能会扼杀团队的生产力，我们将很难优化和扩展应用程序。
即使是的模块化单体应用程序也将为其所有模块提供一个集中式数据库。
我相信，如果我们尝试在生产中找出一个闲置的模块式单片机应用，我们将会非常困难。
微服务应用程序的核心概念是分散化，它提供了模块之间的硬线和分散的数据存储。通过设计，开发人员很难跨越这条线，这有助于实现真正的模块化应用程序。
最终的结果给我们带来了好处，我们已经提到过了。因此，我们应该在下列情况下选择“微服务”：
模块化和是任何项目开始时的一个重要方面。
应用程序将有大量的事务。
与短期利益相比，对长期利益的偏好。
在初始阶段，正确的设计、开发和部署应用程序的人员的可用性:已经观察到，开始一个基于微服务的项目的最初的努力更多的是与一个单一的项目相比较。
使用尖端工具和技术的承诺:微服务是非常年轻的架构方法;支持它的工具和技术是非常新的或快速变化模式。
结论
微服务体系结构不是一种新方法;它的灵魂以SOA(面向服务的体系结构)、web服务和模块化和分层架构的形式存在多年。
它之所以获得成功，主要是由于以下因素：
无法从像单体架构这样的体系结构中获得期望的输出，这是一种挫折。
能够轻松地开发和部署微服务应用程序的工具和技术。
广泛地将基础设施作为服务(IaaS)，如Amazon Web Services，谷歌云平台，或其他，为方便DevOps操作打开了方便之门。
大技术产品公司更适应微服务架构。
在未来的几年里，软件工程师们将会使用微服务架构进行原型开发，这并不奇怪。在物联网时代，谁不想拥有模块化、高性能和易于扩展的应用程序?