无论他们是访问网站还是移动应用，人们对他们经常使用的应用程序抱有很高的期望。 因此，公司必须不断提供新功能和修复。 在过去，这个过程很痛苦，因为应用程序通常是作为单个（通常是单片的）应用程序开发，构建和提供的。

微服务是一种应用程序架构风格，其中应用程序由许多离散的，网络连接的组件组成，称为微服务：

1. 大型单片应用程序被分解为小型服务。
2. 单个网络可访问服务是微服务应用程序的最小可部署单元。
3. 每个服务都在自己的进程中运行。 此规则有时称为“每个容器一个服务”，可能是容器或任何其他轻量级部署机制，例如Cloud Foundry运行时。

客户正在尝试使他们的应用程序现代化，以跟上变化的速度......在过去，操作决定了应用程序的编写方式......人们花了数年时间编写单一应用程序，其中许多应用程序功能都打包在应用程序中。 ..现在他们看到了开发人员在添加新功能以应对不断变化的营销需求方面遇到的困难。----- Roland Barcia，杰出工程师兼首席技术官：微服务

微服务的好处

采用微服务的企业可享受许多好处：

高效的团队

微服务是分成一组可独立部署的小型服务的应用程序。由于微服务旨在独立行动，因此它们自然地与促进端到端团队所有权的敏捷原则保持一致。

简化部署

每个微服务都围绕业务功能构建和对齐，以降低应用程序变更管理过程的复杂性。由于每项服务都是在不影响其他服务的情况下单独更改，测试和部署的，因此加快了上市时间。

适合工作的正确工具

开发微服务的团队可以做出适合工作的技术决策。他们可以尝试新技术，库，语言和框架，从而缩短创新周期。

提高应用质量

由于微服务的“分而治之”方法，微服务的功能和性能测试都比单片应用程序更容易。微服务架构适用于测试驱动的开发，因为组件可以单独测试，并与完整或虚拟化的微服务组合。这种方法可以全面提高应用质量。

可扩展性

微服务比单片应用程序更容易扩展。通过根据各个服务对整体应用程序，吞吐量，内存和CPU负载的关键性来扩展各个服务，团队可以更有效地扩展应用程序。

微服务原则

在为应用程序开发微服务时，请记住以下原则：

单一职责

每个微服务必须针对单个功能进行优化。每项服务都更小，更易于编写，维护和管理。罗伯特马丁称这一原则为“单一责任原则”。

单独的流程

微服务之间的通信必须通过REST API和消息代理进行。从服务到服务的所有通信都必须通过服务API进行，或者必须使用显式通信模式，例如Hohpe的Claim Check Pattern。

执行范围

虽然微服务可以通过API公开自己，但重点不在于接口，而在于运行组件。此图中突出显示了微服务应用程序的粒度：

微服务API通信

CI / CD

每个微服务可以连续集成（CI）并连续交付（CD）。当您构建由许多服务组成的大型应用程序时，您很快就会意识到不同的服务以不同的速率发展。如果每个服务都具有唯一的持续集成或连续交付管道，则该服务可以按照自己的进度进行。在整体方法中，系统的不同方面都以系统中最慢的移动部分的速度释放。

弹性

您可以将高可用性和群集决策应用于每个微服务。当您构建大型系统时，您拥有的另一个实现是，当涉及到群集时，一个大小并不适合所有。在同一级别上扩展整体中所有服务的单一方法可能导致服务的过度使用或使用不足。更糟糕的是，当共享资源被垄断时，服务可能会被忽略。在大型系统中，您可以将不需要扩展的服务部署到最少数量的服务器以节省资源。其他服务需要扩展到大数量。

将应用程序迁移到微服务

微服务是一个小应用程序，通常包含一个功能。该功能通过API和消息传递。每个微服务都可以拥有自己的DevOps管道，可以单独扩展，并拥有自己的数据库，拥有数据模型。

该图显示了单片应用程序架构如何演变为基于微服务的应用程序架构：

微服务示例概述

在单片应用程序中，代码位于单个服务器上。更新单个组件时，必须同时部署其他组件，因此需要一个完全等效的服务器，以通过蓝绿色部署满足高可用性要求。

在重构的微服务应用程序中，简化了更新部署，因为业务服务在独立的基于云的计算基础架构上独立运行。

要了解微服务应用程序的工作方式以及从单片应用程序迁移到微服务，请观看此视频：

下一步是什么？

既然您已了解使用微服务的概念和价值，请通过阅读微服务参考架构了解有关如何设计微服务应用程序的更多信息。在了解了体系结构之后，请参考教程在Kubernetes上部署微服务应用程序。

原文：https://www.ibm.com/cloud/garage/architectures/microservices

本文：http://pub.intelligentx.net/improve-time-market-microservices

讨论：请加入知识星球或者小红圈【首席架构师圈】