微服务架构：是什么？何时用？如何用？

2021-01-13 16:08:47

点击▲关注 “IT168企业级”给公众号置顶

更多精彩时间直达

引言

微服务近年来受到了极大的关注并成为趋势，不信的话可以查看 Google Trends。

可以看到从2014年开始人们对它产生了极大的兴趣，随着时间的推移，这一趋势仍在增长。

对微服务的炒作使得它正处于 Gartner “技术热门度曲线” 中的泡沫期。

即便是处于泡沫期，微服务架构还是值得我们学习的。使用微服务有一定的风险，因此需要投入大量时间去理解它。截至目前，微服务似乎还是非常有前景的。

对它的这种炒作也是有原因的，Netfilx、Amazon 等许多大公司都介绍过他们是如何使用微服务架构来扩展服务和减轻持续交付服务的压力。

微服务架构设计似乎并没有被忽视，它正是 Docker、CoreOS 、IaaS（云计算）这类新兴创业公司的核心卖点。

这些新产品减轻了基于微服务架构的应用程序的开发和部署工作。

Docker 是一种开源的容器技术，它能让多个独立的应用（或服务）在单个 Linux 操作系统上运行，效果就像是这些应用运行在自己独立的操作系统中一样。在过去的几年中，Docker 成长非常快，它的主要发起公司 Docker Inc. 公司在获得资金的同时，其市值已超过 10 亿美金。

相信已经有足够多的理由让我们对这一架构进行全面分析。

本文，我们将详细介绍微服务，并解答如下几个问题：

微服务是什么？
什么时候用它？
应该如何用它？

微服务是什么？

当我们将微服务架构和单体应用作对比的时候更有意义。

在单体应用设计中，我们会创建一个庞大的应用程序，其中所有模块都紧耦合并打包在一个可执行文件中，该可执行文件通常部署在 Web 服务器或应用服务器上。

典型的单体应用架构如下所示：

这种架构设计有一些缺点，这些缺点或不足已经成为微服务架构的优势：

无法频繁并轻松的版本发布——随着单体应用的功能逐渐增长，由于各组件之间的紧耦合，很难轻松频繁的进行版本发布。版本发布计划占用了各个小组人员的大量时间，因此不建议频繁发布版本，以确保应用程序不会由于新发布的版本而中断服务。
持续交付中的问题——在小型单体应用中，我们可能不会注意到这个问题。在大型单体应用中，部署时间之慢令人沮丧。即使一个很小的代码改动，也需要重新部署整个应用，这可能成为频繁部署的障碍，从而阻碍持续交付。如果你在开发一个手机应用，用户一直在期待新酷的新功能，那么部署时间太慢可能成为一个严重的问题。
难以管理团队和项目——项目管理在单体应用开发中面临挑战。即使是模块化应用程序，在部署和发布方面也具有相互依赖性。规划版本发布和管理紧耦合的相互依赖的模块开发需要耗费大量时间和精力。
昂贵的可扩展性和高性能——单体应用可以进行扩展但是成本非常高。
缺乏技术多样性——当我们在为单体应用选择技术栈的时候，我们会考虑选择一个较为全的技术栈，从而能满足我们所有的需求，不会为满足特定需求而采用特定技术。
难以替换组件——在不影响整个架构的情况下，很难使用设计和性能更好的组件替换原组件。

微服务的定义

简而言之，微服务是一种架构风格，由多个可以独立部署的应用组件组成。这些独立的应用组件使用 RMI（远程方法调用），Restfull Web Services 或者 Push Messaging 相互通信。

以下是典型的基于微服务架构的应用程序设置：

在用微服务架构设计系统时，我们应当合理划分组件/模块，每个组件都是一个微型应用程序，将会单独进行开发，并且遵循各自的开发和部署周期。

如果我们要开发一个学校管理系统，它由学生注册、出勤、费用、评估等各种重要组件组成。

当使用微服务架构开发这个应用时，我们将独立部署用于学生注册、出勤、费用和其他模块的微型应用程序。

通常我们可能会遇到这样的场景：对于单个请求，需要来自多个组件的数据。理想情况下，会有一个 API 网关或前端控制器，用来聚合来自这些组件的数据并将其返回。

组件之间需要进行通信，它们可以通过 REST API 或 RMI（远程方法调用）进行通信。

基于微服务架构的应用程序的特点如下：

组件独立运行并能对外提供服务。
组件根据业务功能进行划分。
整个项目都采用产品化思想。
组件使用 RESTish 协议或轻量消息队列进行通信。
没有统一规范，每个独立组件都可以使用其专有的规范进行开发和部署。
数据分散管理，在上图中观察各个组件是如何管理自己的数据存储。
自动化的基础架构管理，我们需要依靠自动化的基础架构管理来降低独立组件部署的复杂性。
应用设计时要考虑故障处理。应用由多个独立组件构成，我们需要妥善处理接收方未收到响应的情况。
一个佳的微服务架构设计，可以在不影响其他协作者的情况下对其进行替换和升级。

不足

就像硬币有两面一样，微服务架构也有一系列问题。我们已经介绍了它的优势，再研究下它的不足会对我们很有帮助。

在基于微服务架构的应用中，有一些不足或需要改进的地方：

团队沟通开销——微服务架构虽然能够减少团队管理的复杂性，但却无法减少团队沟通的的需求。开发团队需要确保一个团队的服务更新不会影响另一个团队的功能。在单体应用中也有这个问题。
维护文档开销——每个组件的开发人员都需要实时更新架构和接口文档，这样才能帮助正在使用该服务的其他团队。
多样的技术栈——每个组件都可能使用不同的技术栈，这样会导致应用程序设计和架构不统一的问题。从长远来看，可能会增加运维成本。
开发运维复杂度——需要一只专业 DevOps 团队来运维基于微服务的应用。由于应用程序的组件随时可能漂移，使得维护它变得复杂并且需要一定的专业技能。
资源使用增长——运行这些应用程序的初始投资很高，因为所有这些独立运行的组件都需要有更多内存和 CPU 的运行时容器。
网络通讯增长——独立运行的组件使用网络进行交互。这样的系统需要快速可靠的网络连接。
编码与解码——当一个组件需要来自另一个组件的数据时，发送方按照约定的标准对数据进行编码，而接收方在使用前按照约定的标准进行解码，与传统的应用架构相比需要更多的处理。
网络安全——服务间的通讯需要加密以避免任何安全漏洞。由于有多个活动组件，这些应用程序更容易出现安全漏洞。
测试——相较于单体应用，测试微服务架构的应用更难。

生产环境监控——监控微服务架构应用的成本更高，监控工具的不可用也需要考虑。
高昂的前期成本——与单体应用相比，微服务应用的运行成本更高。

上面提到的所有问题都可以通过更多的努力或使用合适的工具来解决。单体应用也面临同样的问题。

下面，我们将讨论什么情况下应该使用微服务架构，让我们一起来回答这个问题——我们应该何时以及如何使用微服务架构？

我们应该何时以及如何使用微服务架构？

如果我们在 Google 搜索有关微服务架构的使用情况，则会看到许多成功使用该架构的案例。如下是已经使用它的产品和公司：

Netflix
eBay
Amazon
其他一些大中型科技产品公司

我们应该通过如下两种方法在任何产品/项目中使用微服务架构：

仅限单体或单体优先
微服务优先

仅限单体或单体优先

上面提到的公司近来都将其应用程序从单体改为微服务架构。虽然开始的时候都是单体应用的形式，但现在已经稳步迁移到微服务架构。因此，这使得我们开始思考微服务是否可能更适合非常庞大和复杂的应用程序。

在以下情况下，我们应该选择仅限单体或单体优先：

企业尚未准备好投资基于微服务的应用程序产生的前期成本。
企业无法遇见微服务优先带来的价值。
没有足够的人力来构建和运行基于微服务的应用程序。
软件交付时间紧迫：有时候，单体应用有助于迅速进入市场。
担心什么时候有用于支持微服务应用顺利部署的工具和技术。

牢记上述几点有助于我们决定何时使用仅限单体或单体优先的方法。

尽管我们无法否认微服务应用程序是理想的选择，但我们必须权衡取舍。通常，当单体应用程序在规模和性能方面需要提升时，我们会选择微服务。我们可以通过两种方式使用微服务：

对单体应用中设计良好的模块化组件进行扩展——通常，我们发现企业支持单体优先的设计，并认为如果需要的话，可以很容易将模块化设计的单体应用转换成微服务。企业选择模块化的单体应用，以减少开发微服务时可能产生的成本。但这只是一个遥远的梦想，与现实相去甚远。
对现有的单体应用使用微服务架构进行重构——通常，由于单体应用中不良的模块化设计，我们都是从零开始开发微服务应用程序的。

微服务优先