什么是微服务？
微服务，也称为微服务架构，是指将应用程序构建为组合服务集合的软件开发方法。从本质上讲，这套应用程序是作为一个完整的应用程序部署的，并且这些服务共同构成了整个应用程序。微服务都遵循以下模式：它们围绕业务能力进行组织，松散耦合，可独立部署，并且是可测试的。由于微服务是松散耦合的，因此可以独立构建、部署和扩展。
每项服务都通过标准化的应用程序编程接口 (API) 与其他服务进行通信，从而可以用不同的语言或不同的技术编写服务。这与作为整体结构构建的系统完全不同，在整体结构中，服务密不可分，只能一起扩展。
由于每项服务都有有限的，通常是单一的功能，因此它在规模和复杂性上都要小得多。微服务一词来自这种离散的功能设计。
通过将应用程序分解为实现特定业务功能的分立服务，微服务为现代开发人员提供了一种设计可高度可扩展的灵活应用程序的方法。
为什么选择微服务？
微服务之所以越来越受欢迎，是因为它们的模块化特性带来了灵活性、可扩展性并减少了开发工作量。它们的部署灵活性以及云原生无服务器和功能即服务部署选项（例如 AWS Lambda 和 Microsoft Azure 云功能）的兴起，为微服务在当今 IT 格局下蓬勃发展创造了理想环境。这些云平台使微服务和功能可以从不活动状态扩展到高容量，然后再进行扩展，而客户只需为其使用的计算容量付费。
随着企业不断寻求提高敏捷性、减少瓶颈以及缩短应用程序交付时间，微服务架构越来越受到欢迎。
过去，各公司开发了具有三个主要组件的专用企业应用程序：
- 面向客户端的界面，通常是运行在用户计算机上的 HTML 页面
- 数据库，通常是关系数据库管理系统中的许多表
- 处理所有请求（如数据检索、HTTP 请求和填充 HTML 浏览器）的服务器端应用程序。
对于用户来说，一切似乎都是通过单点联系进行的。开发、测试和部署使用部署管道，并且您可以通过运行多个实例进行横向扩展。
但是，它们的开发成本相当高，任何更改都需要全面的系统重新设计、重建和重新部署，随着组织的发展和变化，很难保持一个干净的模块化结构，而且无论修订多小的更改，扩大规模都需要对整个应用程序进行重新测试、扩展和重新部署。所有这些问题导致了一个昂贵的非敏捷系统，而这个系统很快就跟不上技术格局的快速发展。
可以将这些传统整体系统看作是现成的玩具屋。虽然你可以编辑结构或布局，但这并不容易，而且整体大小也是有限的，除非你再购买一个玩具屋并将其连接到原有玩具屋。
使用微服务，不需要重新部署整个应用程序，只需要重新部署需要它的服务。微服务不是一个像玩具屋一样的单一结构实体，而是像一堆乐高积木。从技术上讲，它们都是独立的，但是当它们组合在一起时，就形成了一个完整的结构应用程序。如果要添加分割或终止某些内容，可以轻松地将其删除、添加、放大和编辑，以快速有效地满足不断变化的需求，而无需关闭整个应用程序。
微服务架构的好处
对于希望采用微服务并将其集成到其产品中的企业来说，有许多显著的好处，下面将更详细地探讨这些好处。
加快上市时间
能够快速添加和删除功能意味着业务可以变得极其敏捷。添加新功能可以快速完成，跟上业务增长的步伐。与传统的整体式软件不同，系统中某一部分的代码更改不会影响其他模块，因此无需进行额外的测试、关闭整个应用程序或重新部署所有内容。
更高的功能和更低的运营成本
由于微服务中的模块都是独立的，因此导致整个应用程序失败的潜在漏洞或错误的风险要小得多。与传统的软件系统不同，在传统软件系统中，一部分功能的的更改可能会导致另一部分出现缺陷或漏洞，而隔离和松散耦合则可以实现分开升级和增强。微服务还允许使用云原生功能即服务的部署选项，这可以显著降低运营成本。
可轻松扩展的应用程序
微服务的扩展决策是在粒度级别做出的，从而为系统优化做出最有效的决策。通过采用微服务，当需要扩大规模时，组织能够立即做出最适合自己的选择。
持续集成
微服务是使用单独的持续开发和部署流开发的。这些流可以持续进行，因此当一个团队根据客户反馈实施变更时，另一项服务不会中断，这意味着最终用户的满意度得到提升。
专门的开发人员团队
与无法维持多个开发团队的整体系统不同，微服务有能力为专门负责系统某些特定部分的团队提供支持。由于软件模块之间不相互影响，因此不存在漏洞或跨团队工作重叠的风险，因此微服务团队可以拥有专业的软件开发人员以及跨不同时间范围或地理位置工作的团队。
所有这些好处加起来可能就是最重要的好处：业务敏捷性。可以快速进行简单的微小更改，从而可以对过程进行实验。借助微服务，能够在业务上实现巨大飞跃，或者至少快速失败并进行实时响应。此外，研究发现，在部署微服务架构后的几个月内，三分之一的组织开始获得优势。这意味着缩短了开发时间，随着代码错误的减少和功能的提高，几乎可以立即感受到对业务运营的积极影响。
微服务的特征
- 松散耦合
- 可独立部署的组件
- 自动部署
- 去中心化数据和语言控制
- 高度可维护
- 易于测试
- 围绕企业或组织的需求和能力进行组织
- 每项服务往往由一个小团队拥有
微服务面临的挑战
尽管微服务确实解决了许多问题，但在架构上以及在最初采用架构时，仍然可能会遇到一些困难和问题。
去中心化数据管理
与整体系统不同，微服务通常不依赖于作为公司数据单一真实来源的数据库。客户数据可能在一个地方，而供应商数据可能在另一个地方。也许库存信息存储在在线销售门户网站中，但订购系统保存在单独的数据库中。这可能会给数据质量和一致性带来问题，除非为此做了具体的规划。
企业文化和内部组织挑战
要让公司接受和适应新的软件系统可能很困难。通常，管理层可能不愿放弃控制权，或者一个部门会自己的孤岛进行辩解。不管团队抵触接受新系统的原因是什么，至少我们知道，人们有时候就是不喜欢改变。
要使微服务在整个组织范围内得到采用，至关重要的是要认识到引入新系统和流程可能会造成不安，但同样重要的是要记住这些好处是值得的。在开始向微服务过渡时，最好在规划架构时让受影响的团队参与进来。制定计划以评估可用的解决方案，并确保为业务需求选择最合适的解决方案。
微服务可能导致架构的复杂性
虽然构成微服务的单个服务本身可能很小而且很简单，但结合起来时，整个应用程序最终可能会有许多移动部分，变得难以管理。由于有成百上千的互连，微服务的复杂性会迅速增加。
建议在实施微服务时，在设计和基本实施中要有大量的预见和规划。良好的基本架构设计可以避免许多复杂性，可满足将来的增长和变化。
微服务架构用例示例
采用云原生部署选项：利用无服务器和功能即服务实现更高效、更可扩展的运营。
从原有应用程序迁移的功能：从大型整体式应用程序中分解服务，以便它们可以独立维护和扩展。
利用现代应用程序架构：采用事件驱动、松散耦合的微服务应用程序模式，并能够根据用例需求利用不同的编程语言。例如，去计算繁重的函数，Node.js 用于快速网络应用程序等等。
什么是 DevOps 以及为什么常与微服务相关联？
DevOps 可以解释为以工具为中心的思想。从本质上讲，这是一套将工具和技术结合在一起的实践，以简化开发人员需要完成的工作。除了改进工具外，运营和开发团队之间的合作还有助于推动项目更加快速高效地完成。
例如，假设您正在构建一个允许用户查看其帐户余额的应用程序。过去，在应用开发周期中，开发人员通常会先构建应用程序，然后将其交给运营团队，而不对最终结果负责。让应用程序正常运行是运营团队的工作。在更具凝聚力的 DevOps 环境中，双方协同工作。开发者自始至终拥有应用程序的生命周期，这意味着在发布期间处于待命状态。为确保一切顺利，并充分获得 DevOps 的好处，如加快上市速度、更轻松的开发周期和更多的问责制，两个团队之间必须保持一致的沟通。
新的 DevOps 工作流模型带来了重大的文化转变。仅使用新工具并不能使 DevOps 计划成功。如果有什么新工具可能会阻碍成功，如果它们使您毫无疑问地相信一切都会适当地实施。
由于微服务的性质，部署通常需要强大的 DevOps 流程。增加工具使用和强化共享做法使团队免于被所有微笑的移动部分压垮。您可以减少这种转变带来的干扰或负担，同时继续获得好处。
未来趋势：事件驱动的微服务、无服务器计算和功能即服务 (FaaS)
当人们第一次开始尝试微服务时，他们通常会默认使用熟悉的技术，例如 RESTful API。REST 基于请求-响应形式的通信。这种同步方法的问题在于，由于您必须等待响应，因此服务变得相互依赖。这意味着，如果某项服务运行速度较慢或没有响应，则调用该服务的运行速度将变慢或失败。这种耦合可能意味着失去微服务架构的一些好处，从而创建一个类似于面向服务的架构 (SOA) 风格的更加相互依赖的结构。
如果您使用 Beyond-REST 或事件驱动模型设计服务，则可以确保部分应用程序继续工作，不会牵涉其他部分，而不是整个应用程序无法响应。Netflix 就是一个很好的例子。有时，您可能会注意到 “继续观看” 按钮没有出现。这是因为该特定服务不可用。但是，这并不意味着所有的 Netflix 都会停止。用户仍然可以浏览节目和观看预览，因此 Netflix 即使一项服务可能无法使用，其他服务仍然运转正常并可供使用。
完全采用微服务方法的开发人员意识到，通过松散耦合和事件驱动架构可实现真正的可扩展性。服务可以是异步的，可以执行操作、广播消息以及继续使用其主要功能，无需等待其他服务的响应。
微服务如何运作？
微服务并非新创意。三十多年前，Unix 开发了一款 SOA，它使用了类似的设计原则，但实施成本很高，而且经常失败，对企业来说并不是一个好选择。二十年后，微服务跨服务的一致性大大提高，自那以后微服务的采用越发成功。
至于微服务的实际工作方式，软件功能首先分解为独立的小模块。这些模块定义了独立的任务。然后，系统通过使用应用程序编程接口 (API) 将这些小块软件链接在一起来工作。
API 是让两个不相关的程序彼此来回 “交谈” 的代码片段。一个实际应用的 API 示例是嵌入了 Google 地图的应用或网站。Google 地图和应用之间有一个 API 来回发送信息，允许用户实时查看他们的地图、给司机指示，还可以向您信任的联系人提醒您的位置。虽然 Google 地图仍然是一个独立的实体，但 API 允许在地图和应用程序之间来回通信。因此，您拥有的是一些有用的乐高小积木，它们使用 API 作为连接器点击在一起，而不是预制玩具屋，一切都是有计划的、僵化的、难以改变的。标准化技术平台可能有局限性，但并非每个问题都是钉子，也不是每个解决方案都是锤子。微服务为这项工作提供了合适的工具。
微服务有一定的好处，成功采用微服务作为架构模型的公司已经从更快、更敏捷的业务 IT 结构中受益。但是，一些组织发现该系统是生产力杀手和运营负担。成功与失败的区别在于两个部分：组织的文化及其接受和使用微服务的意愿，以及设计实现微服务的规划和预想。
通常，新系统的真正收益或成本在很多年后才会实现。在这些年里，整体式架构有时已经不合时宜或已经开始衰退。微服务内部出现这种衰退的可能性较小，并且修补问题要简单得多。
解决这些潜在问题的一种方法是从整体开始。这样一来，基础软件可以在您扩大规模时加入其他东西，形成类似带有乐高扩展套件的玩具屋。虽然这种方法可能并不巧妙，但它是企业继续向前发展的一种方式，尤其是在现有数据库或程序处于运营核心的情况下。