微服务架构：是什么？何时用？如何用？
（给Go开发大全加星标）
英文：Mrityunjay Kumar，翻译：解博
微服务近年来受到了极大的关注并成为趋势。从2014年开始人们对它产生了极大的兴趣，随着时间的推移，这一趋势仍在增长。
微服务是什么？
什么时候用它？
应该如何用它？
这种架构设计有一些缺点，这些缺点或不足已经成为微服务架构的优势：
无法频繁并轻松的版本发布——随着单体应用的功能逐渐增长，由于各组件之间的紧耦合，很难轻松频繁的进行版本发布。版本发布计划占用了各个小组人员的大量时间，因此不建议频繁发布版本，以确保应用程序不会由于新发布的版本而中断服务。
持续交付中的问题——在小型单体应用中，我们可能不会注意到这个问题。在大型单体应用中，部署时间之慢令人沮丧。即使一个很小的代码改动，也需要重新部署整个应用，这可能成为频繁部署的障碍，从而阻碍持续交付。如果你在开发一个手机应用，用户一直在期待最新最酷的新功能，那么部署时间太慢可能成为一个严重的问题。
难以管理团队和项目——项目管理在单体应用开发中面临挑战。即使是模块化应用程序，在部署和发布方面也具有相互依赖性。规划版本发布和管理紧耦合的相互依赖的模块开发需要耗费大量时间和精力。
昂贵的可扩展性和高性能——单体应用可以进行扩展但是成本非常高。
缺乏技术多样性——当我们在为单体应用选择技术栈的时候，我们会考虑选择一个较为全的技术栈，从而能满足我们所有的需求，不会为满足特定需求而采用特定技术。
难以替换组件——在不影响整个架构的情况下，很难使用设计和性能更好的组件替换原组件。
以下是典型的基于微服务架构的应用程序设置：
在用微服务架构设计系统时，我们应当合理划分组件/模块，每个组件都是一个微型应用程序，将会单独进行开发，并且遵循各自的开发和部署周期。
如果我们要开发一个学校管理系统，它由学生注册、出勤、费用、评估等各种重要组件组成。
当使用微服务架构开发这个应用时，我们将独立部署用于学生注册、出勤、费用和其他模块的微型应用程序。
通常我们可能会遇到这样的场景：对于单个请求，需要来自多个组件的数据。理想情况下，会有一个 API 网关或前端控制器，用来聚合来自这些组件的数据并将其返回。
组件之间需要进行通信，它们可以通过 REST API 或 RMI（远程方法调用）进行通信。
基于微服务架构的应用程序的特点如下：
组件独立运行并能对外提供服务。
组件根据业务功能进行划分。
整个项目都采用产品化思想。
组件使用 RESTish 协议或轻量消息队列进行通信。
没有统一规范，每个独立组件都可以使用其专有的规范进行开发和部署。
数据分散管理，在上图中观察各个组件是如何管理自己的数据存储。
自动化的基础架构管理，我们需要依靠自动化的基础架构管理来降低独立组件部署的复杂性。
应用设计时要考虑故障处理。应用由多个独立组件构成，我们需要妥善处理接收方未收到响应的情况。
一个最佳的微服务架构设计，可以在不影响其他协作者的情况下对其进行替换和升级。
不足
在基于微服务架构的应用中，有一些不足或需要改进的地方：
团队沟通开销——微服务架构虽然能够减少团队管理的复杂性，但却无法减少团队沟通的的需求。开发团队需要确保一个团队的服务更新不会影响另一个团队的功能。在单体应用中也有这个问题。
维护文档开销——每个组件的开发人员都需要实时更新架构和接口文档，这样才能帮助正在使用该服务的其他团队。
多样的技术栈——每个组件都可能使用不同的技术栈，这样会导致应用程序设计和架构不统一的问题。从长远来看，可能会增加运维成本。
开发运维复杂度——需要一只专业 DevOps 团队来运维基于微服务的应用。由于应用程序的组件随时可能漂移，使得维护它变得复杂并且需要一定的专业技能。
资源使用增长——运行这些应用程序的初始投资很高，因为所有这些独立运行的组件都需要有更多内存和 CPU 的运行时容器。
网络通讯增长——独立运行的组件使用网络进行交互。这样的系统需要快速可靠的网络连接。
编码与解码——当一个组件需要来自另一个组件的数据时，发送方按照约定的标准对数据进行编码，而接收方在使用前按照约定的标准进行解码，与传统的应用架构相比需要更多的处理。
网络安全——服务间的通讯需要加密以避免任何安全漏洞。由于有多个活动组件，这些应用程序更容易出现安全漏洞。
测试——相较于单体应用，测试微服务架构的应用更难。
生产环境监控——监控微服务架构应用的成本更高，监控工具的不可用也需要考虑。
高昂的前期成本——与单体应用相比，微服务应用的运行成本更高。
上面提到的所有问题都可以通过更多的努力或使用合适的工具来解决。单体应用也面临同样的问题。
下面，我们将讨论什么情况下应该使用微服务架构，让我们一起来回答这个问题——我们应该何时以及如何使用微服务架构？
Netflix
eBay
Amazon
其他一些大中型科技产品公司
我们应该通过如下两种方法在任何产品/项目中使用微服务架构：
仅限单体或单体优先
微服务优先
在以下情况下，我们应该选择仅限单体或单体优先：
企业尚未准备好投资基于微服务的应用程序产生的前期成本。
企业无法遇见微服务优先带来的价值。
没有足够的人力来构建和运行基于微服务的应用程序。
软件交付时间紧迫：有时候，单体应用有助于迅速进入市场。
担心什么时候有用于支持微服务应用顺利部署的工具和技术。
牢记上述几点有助于我们决定何时使用仅限单体或单体优先的方法。
尽管我们无法否认微服务应用程序是理想的选择，但我们必须权衡取舍。通常，当单体应用程序在规模和性能方面需要提升时，我们会选择微服务。我们可以通过两种方式使用微服务：
对单体应用中设计良好的模块化组件进行扩展——通常，我们发现企业支持单体优先的设计，并认为如果需要的话，可以很容易将模块化设计的单体应用转换成微服务。企业选择模块化的单体应用，以减少开发微服务时可能产生的成本。但这只是一个遥远的梦想，与现实相去甚远。
对现有的单体应用使用微服务架构进行重构——通常，由于单体应用中不良的模块化设计，我们都是从零开始开发微服务应用程序的。
如果模块化是选择微服务的主要原因，为什么在单体应用中不可能出现呢？毕竟我们在单体应用中也可以使用模块化设计。
下图展示了我们对于应用程序模块化的期望以及我们实际得到的：
我认为答案在于我们开发软件的方式以及软件如何从小型发展到大型。在单体应用中，我们总是企图快速地开发，并且由于没有定义硬性边界，我们可以这样做。在快速开发的同时，我们失去了模块化。从长远来看，这些重叠的模块化功能会降低团队的工作效率，并增大了优化和扩展应用程序的难度。
即是一个空闲的模块化单体应用也具有一个集中式数据库。
我相信，我们很难在生产环境中找到一个空闲的模块化单体应用。
微服务应用程序将去中心化作为其核心概念，它在这些拥有去中心化的数据存储的模块之间设置了界限。通过设计，开发人员很难跨越界限，并且有助于强化应用程序的模块化。正如我们已经提到的，这一结果对我们有益。
因此，如下情况，我们应该选择微服务优先：
任何项目开始时，模块化和去中心化都是一个重要方面。
重点关注的应用程序将具有大量交易或流量。
与短期收益相比，偏向长期获益。
初期，有合适的人员来快速设计、开发和部署应用程序 — 我们观察到，与单体应用相比，启动一个基于微服务的项目的初期工作更多。
致力于使用最先进的工具和技术——微服务是非常年轻的架构方法；支持它所需的工具和技术都很新并且处于快速更新的模式。
它主要由于以下原因而获得发展势头：
无法从单体应用获得预期输出的极度沮丧。
开发和部署微服务应用的工具和技术的轻松使用。
基础架构即服务（IaaS）的广泛使用，例如 Amazon Web Services，Google Cloud Platform 等，为轻松的 DevOps 操作打开了大门。
大型科技公司采用微服务架构。
在未来的几年中，微服务架构将发展到更高水平，单体应用将只被用来进行原型设计。试问谁不想在互联网时代拥有一个模块化、高性能并且易于扩展的应用程序呢？
- EOF -
如果觉得本文不错，欢迎转发推荐给更多人。
分享、点赞和在看
支持我们分享更多好文章，谢谢！