微服务的定义和主要应用

微服务是用于复杂 Web 应用程序的软件架构，它基于一个完全 "不复杂" 的概念：在云端上，将系统的每个主要功能封装为一个小型的、半独立的、并且是基于网络的服务。特定的微服务是一个几乎独立的软件程序，它的存在只是为了执行单个（这可能是非常复杂！）的任务，作为同一平台其他组件的更大平台的一部分。

关于微服务，首先要了解的是……

微服务不是 API

它们用于使大型软件平台更加模块化可能会给人一种印象，即微服务只是应用程序编程接口（API）, 目前已经存在数十年的迷人名称——事实并非如此！

API 是规则或库，仅实现软件程序之间的交互，而不是每个程序实际执行的操作。API 毫不含糊地描述了可以交换哪些数据格式、哪些命令是可接受的及其可能的回复以及类似的任务。因此，完全不同的程序可能会使用相同的 API。同时，微服务目前是众多应用程序类别中最受欢迎的，这些应用程序需要 API 首先是有用的，并且是可管理的。

主要微服务类型和风险

就其本身的性质而言，微服务是很多不同的程序之总称，这使得不可能在一篇短文中完整地描述它们。尽管如此，对于每一种微服务，至少有几件事是有效的，并且是必须了解的。

从技术上讲，微服务可以是无状态的或有状态的，由于这种分类对其实现产生巨大影响，因此正确处理它至关重要。“无状态” 表示在与相同或不同用户（无论这些“用户”可能是谁，即其他微服务、第三方应用程序或人们）。在无状态微服务中，每个事情都像第一个事情一样发生。这使它们更易于构建、测试和维护。然而，在许多情况下，这种 “无状态” 是不可能的。另一种或备用解决方案是状态性，即微服务存储会话数据或某些数据库中每次交互的日志，以便在需要时重用它们。

关于所有微服务，另一个需要了解的关键是，它们必须尽可能是独立的。但是，例如，如果负责同一平台的一个微服务的每个团队都采用不同的语言，把任何语言发现的所有漏洞加起来，这可能会使系统面临更多种类的攻击。

微服务是很大的

虽然一般原则当然不是新的，但微服务在过去几年中爆炸性地增长！

根据 IBM 的一项调查，在 2021 年初，微服务最常用于数据分析、商业智能和数据库应用程序。截至 2021 年底，微服务的主要用戶包括亚马逊、IBM、微软、Netflix 和甲骨文，而这些只是您在此处和 2021 年其他市场报告中提到的一些比较知名用户而矣。

同样的技术也在服务行业之外迅速传播，特别是在制造业：蒂森克虏伯通过微服务管理物联网设备来处理电梯的预测性维护，一些公司在 AWS 上运行微服务，尽量以最低的成本控制他们的制造工厂。总的来说，分析师的分析正确的话，"云微服务市场应该 “在 2026 年达到 27.0136 亿美元，复合年增长率约为 21.7%” 。

何时以及为何使用微服务

微服务可能在任何大型组织的基础架构以及每个软件开发人员的产品组合中都扮演着非常重要的角色。在已经提到的调查中，最常报告的微服务优势是在添加或删除资源或功能，以更容易适应不断变化的业务需求，从而帮助转化为更高的客户满意度。

这并不足为奇。由于微服务的体积更小，并且尽可能与平台的其余部分分离，微服务更容易频繁更新，对系统其余部分的风险最小。反过来看，这使得更新或扩展更大的应用程序更容易，不管其目的是什么，或需求经常变化。

换句话说，微服务对于任何复杂软件系统的长期及可持续生产力都非常有用。除了使构建和修改应用程序变得更容易之外，微服务更可以以最符合组织每个部分的目标和工作方式在任何已定的时间进行。

这也适用于在线企业级服务的供应商。像 Gmail 这样的云应用程序永远不会为个人定制各自的行为。然而，面向企业客户在基于云的工资管理平台将是完全不同的情况。此类服务的供应商有意提供不同版本的系统，例如一种用于欧盟公司，一种用于美国公司，依此类推。但是，如果这些版本仅针对一个或几个特定功能而有所不同，那么将这些功能作为两个独立的微服务提供，这与比整个应用程序只具有单一架构相比，可以更容易让所有客户满意。

如果现有应用程序越来越难以现代业务环境所需的速度和频率进行更新和维护，那么迁移到微服务架构也可能是一个明智的选择。

总言而之，微服务并不能免除其架构师和开发人员执行非常明确的通用规则和监督的责任；恰恰相反，缺乏协调和共同愿景会使基于微服务的平台在许多方面变得不必要地难以管理。要了解有关微服务的更多信息以及它们如何帮助您的组织或职业，请继续关注本系列的下一篇文章。