介绍

在设计应用程序时，应用程序体系结构是一个需要考虑的重点，多年来，许多不同的软件开发范例已经过去，不变的主题是，需要以模块化的方式对软件系统进行组件化。由于许多原因，模块化软件是有益的。它使源代码更易于理解和遵循，开发人员可以可视化代码库并大致了解查找缺陷的位置 - 从而提高维护效率。

如果使用您的应用程序的用户数量增加，那么架构良好的软件系统也更容易扩展，更不用说，如果新开发人员加入您的团队，一个架构良好的系统可以使入职流程更快，并减少开发人员配给时间，因为每个人都是编码到一组特定的标准。

构建软件项目有很多方法，例如N-Tiered，面向服务的体系结构（SOA）或微服务体系结构等等。然而，在这篇文章中，针对软件开发人员，开发经理和CTO，我们专门研究微服务架构并涵盖以下主题：

What is Microservice Architecture? （什么是微服务架构？）
The need for Microservice Architecture （对微服务架构的需求）
Benefits of Microservice Architecture （微服务架构的好处）
Challenges of Microservice Architecture （微服务架构的挑战）
Should You Adopt Microservice Architecture? （你应该采用微服务架构吗？）
Sample Microservice Architecture （示例微服务架构）
Summary （摘要）

当你阅读这篇博文时，你将对微服务架构是什么，它的好处，如果你应该考虑它以及如何构建一个应用程序以采用这种架构范例有一个充分的理解，那么让我们得到开始！

什么是MICROSERVICE架构？

在过去的几十年中，应用程序已经以整体方式开发，从上到下编码为一个单独的单元，有时没有真正的结构或思想用于将来的维护，这可能导致一系列问题。构建不良的软件解决方案也可能会出现问题，无法通过新功能进行调试或扩展，而且通常情况下，处理起来并不是很好。

微服务架构是面向服务的架构（SOA）的一种形式，其中软件应用程序被构建为松散耦合的服务的集合，而不是单个软件应用程序。每个微服务可以独立于另一个创建，或者甚至以完全不同的编程语言创建并独立运行。

在这一切的核心，每个微服务都试图满足您正在处理的特定用户故事或业务需求。它是当今日益增长的互联世界中理想的架构设计模式，有助于支持跨云，移动，物联网（IoT）甚至可穿戴设备的多种平台和设备。

实现微服务的一种流行方式是使用HTTP / REST和JSON等协议作为架构设计模式，我们看到许多主要的SaaS提供商在其解决方案和服务中采用微服务。

从Microsoft到IBM等等，软件供应商和服务提供商正在实施微服务架构。 Twitter，Netflix，eBay和亚马逊等主要厂商也青睐微服务架构，因为它有助于其服务的开发，可扩展性和持续交付。这带来了微服务架构的一些好处。

作为一种架构实践，微服务架构近年来越来越受欢迎，这降低了它可以带来软件开发团队和企业的好处。随着软件复杂性的增加，能够将应用程序中的功能区域组件化为多组独立（微）服务可以产生许多好处，包括但不限于以下内容：

更有效的调试 - 不再跳过应用程序的多个层，实质上是更好的故障隔离
加速软件交付 - 可以使用多种编程语言，从而使您可以访问更广泛的开发人才库
更容易理解代码库 - 提高生产力，因为每个服务代表一个功能区域或业务用例
可扩展性 - 组件化的微服务自然有助于通过REST等行业标准接口与其他应用程序或服务集成。
容错 - 由于更具弹性的服务，减少了停机时间
可重用性 - 由于微服务是围绕业务案例而非特定项目组织的，由于它们的实现，它们可以重复使用并轻松地插入到其他项目或服务中，从而降低成本。
部署 - 因为所有内容都封装在单独的微服务中，您只需要部署已更改的服务而不是整个应用程序。微服务开发的一个关键原则是确保每项服务与现有服务松散耦合。

但是，不要只听我们的话，这里有一些真实的微服务实例，这个架构设计模式如何使沃尔玛和亚马逊受益。

MICROSERVICE架构在真实行动中的行动

在这里，我们探讨如何采用微服务作为软件架构可以增加真正的商业价值，并为亚马逊和沃尔玛带来一系列的好处。

MICROSERVICES拯救了沃尔玛的老化软件架构

零售业巨头沃尔玛的加拿大分支机构在其现有的软件架构方面存在严重问题，特别是在黑色星期五 - 连续两年。在高峰期，沃尔玛网站每分钟无法处理600万次页面浏览量，最终使访问者几乎无法获得任何积极的用户体验。

部分问题在于沃尔玛的软件架构是针对2005年的互联网设计的，该架构以台式机和笔记本电脑为中心。移动，智能和物联网设备的使用尚未完全达到顶峰。该公司决定在2012年使用微服务重新平台其遗留系统，并设定了到2020年能够为40亿个连接提供服务的目标！

通过迁移到微服务架构，沃尔玛确定：

移动订单增加了98％ -
黑色星期五和节礼日的零停机时间（加拿大黑色星期五）
转化次数增加20％

AMAZON

亚马逊零售和现在的物流巨头对大规模交付软件并不陌生。高级AWS产品经理Rob Birgham分享了一个关于微服务架构如何与DevOps结合使用的故事。

早在2000年初，Amazons网站就被开发为一个巨大的单块解决方案，公平地说，很多业务都是以这种方式开始的。然而，随着时间的推移，随着功能区域的建立，来自多个开发团队或错误的修复，更不用说随着平台的发展，整合所有这些工作的工作开始影响整体生产力。

几天或有时整整一周致力于将开发人员更改合并到产品的主版本中，必须再次解决合并冲突，这些都会对生产力产生影响。

很快意识到这样的操作是不可持续的，亚马逊决定通过采用微服务架构来解决他们的整体代码库。每个服务都由一个目的负责，因为可以通过Web服务API访问。

一旦完成此练习，这为亚马逊创建高度解耦的架构铺平了道路，每个服务都可以独立运行 - 为每个开发人员提供相应的Web服务接口定义。

微软架构的挑战

与每个新的软件编程架构一样，每个都有优缺点列表，并不总是桃子和奶油和微服务不是这个规则的例外，值得指出其中的一些。

太多的编码语言 - 是的，我们将此列为一项好处，但它也可能是一把双刃剑。最终，太多的替代语言可能会使您的解决方案变得笨拙并且可能难以维护。
集成 - 您需要有意识地努力确保您的服务尽可能松散地耦合，否则，如果您不这样做，您将对一项服务进行更改，这会对其他服务产生连锁反应，从而使服务集成困难且耗时。
集成测试 - 测试一个单片系统可以更简单，因为一切都在“一个解决方案”中，而基于微服务架构的解决方案可能具有生活在其他系统和/或环境上的组件，从而使配置更加困难并且“端到端”测试环境。
通信 - 微服务自然需要与其他服务交互，每个服务将依赖于一组特定的输入并返回特定的输出，这些通信通道需要被定义到特定的接口并与您的团队共享。当没有遵守接口定义时，可能会发生微服务之间的故障，从而导致时间浪费。

现在我们已经讨论了微服务架构是什么，它的一些优点是什么，看看现实世界中微服务架构的一些例子以及这种范例的好处，你可能想知道微服务架构是否是对于您或您的软件项目而言，这是一个有效的问题。

您应该采用MICROSERVICE架构吗？

您不希望在项目中实现微服务架构只是为了它，所以我们总结了一些要考虑的点，这将有助于您确定该架构模式是否适合您或您的项目。

如果对这些问题中的任何一个回答“是”，那么您可能需要考虑实施微服务基础架构：

您当前的应用程序是否很难维护？
您是否预计您的应用程序将需要处理大量流量？
模块化和代码可重用性是主要优先事项吗？
您的应用程序是否需要在多种设备类型上访问，例如移动设备，物联网和网络？
您的应用程序需要能够扩展需求的特定区域吗？
您是否希望改进软件产品构建和发布流程？

但是，如果对大多数问题的回答是肯定的，那么您可以使用传统的单片应用程序架构：

只需要发货和MVP，来测试市场吗？
在您退休之前，是否已有一个稳定的产品/团队继续使用该产品？
您的产品“在野外”，产生收入和用户社区是否满意？如果是这样，重新发明轮子没有任何意义

参考微软架构

现在我们已经介绍了微服务架构，讨论了一些好处，各自的挑战，并看了一些微服务如何在现实世界中部署的例子，现在是时候从架构和如何看待基本的微服务了它可以设计。在下图中，您可以使用以下3个微服务：

帐户服务
库存服务
送货服务

在这个虚构的应用程序中，每种微服务都以两种方式之一访问：

从API网关（通过移动应用程序）
从Web应用程序（通过用户的Web浏览器）

注意：理论上可能更多，因为架构适合于此。

您可以看到每个微服务还公开了一个专用的REST API，这是定义可以针对相应微服务执行的操作的接口，并将详细说明可以传递到微服务的数据结构，数据类型或POCOS。作为其返回类型。例如，Inventory服务REST API定义可能包含一个名为GetAllProducts的端点，它允许微服务的消费者获取电子商务商店中的所有产品，这可以返回Product对象的列表，即JSON，XML甚至C＃POCO。

由于每个微服务都有自己的职责，并且只能与其各自的数据库进行交互，因此这样构建的解决方案使不止一个开发人员更容易对系统进行更改。通过实施像我们刚刚详细介绍的微服务，您将获得我们之前概述的一些好处。当您使用这种方法推出架构时，确保每个微服务可以完全独立运行非常重要，否则，它会违背追求这种架构方法的目的。