作为软件开发人员，我们已知道思考如何将应用程序因数分解成组件部分。 这是对象导向、软件抽象和组件化的中心模式。 现在，这种因数分解往往以共享库和技术层之间的类与接口呈现。 通常采用一种分层方法，有后端存储、中间层业务逻辑和前端用户界面 (UI)。 过去几年来的变化是身为开发人员的我们，开始为业务驱动的云构建分布式应用程序。

     不断变化的业务需求包括：

• 为吸引新地理区域的客户而大规模构建和操作的一项服务（举例而言）；
  
• 更快速地提供特性与功能，灵活应对客户的需求；
  
• 提高资源利用率以降低成本；

     这些业务要求影响我们如何构建应用程序。

     有关 Azure 实现微服务的方法的详细信息，请阅读微服务：由云支持的应用程序革新。

     单一式设计方法与微服务设计方法

     所有应用程序会随着时间而发展。 成功的应用程序因为有实用性而发展。 失败的应用程序不会发展，最终会被取代。 问题在于现在对要求了解多少，以及未来有何变化？ 例如，如果要为某个部门构建报告应用程序。 可以确定的是，应用程序保留在公司范围内，而且报表的生存期非常短。 那么，选择的方法将不同于构建服务向数千万个客户传送视频内容的方式。

     在已知以后可以重新设计应用程序的情况下，有时向外寻求概念证明才是驱动因素。 过度设计永不使用的功能并没有太大意义。 这就是通常所谓的工程取舍。 另一方面，公司谈论构建云时都期望成长和使用量。 问题在于成长和规模不可预测。 我们想要能够快速创建原型，同时还要了解我们正在通往未来成功的路上。 这是简练的启动方法：构建、测量、学习和迭代。

     在客户端-服务器时代，我们倾向专注于构建分层式应用程序，每一层采用特定的技术。 已针对这些方法派生出“单一式”应用程序一词。 接口通常存在于各层之间，而在一层内的各组件之间采用更紧密耦合的设计。 开发人员设计并分解已编译为库并链接为一些可执行文件和 DLL 的类。

     这类单一式设计方法有一些优点。 设计较简单，组件之间通常通过进程间通信 (IPC) 调用，因此调用更快。 此外，每个人都只测试单一产品，人力资源运用更有效率。 缺点是分层之间紧密耦合，无法缩放单个组件。 如果需要执行修复或升级，则必须等待其他人完成其测试， 因此更难以发挥灵活性。

     微服务解决了这些缺点，更密切配合上述业务要求，但它们本身也都有优缺点。 微服务的优点是通常各自封装较为简单的业务功能，可独立增加或减少、测试、部署和管理。 微服务方法的一个重要优点是团队倾向于以业务方案为导向，而不是以分层方法建议的技术为导向。 实际上，较小的团队可以根据客户方案来开发微服务，并采用他们选择的任何技术。

     换句话说，组织不需要为了维护微服务应用程序而将技术标准化。 拥有服务的单个团队可以根据团队的专业知识，或什么最适合解决问题，各自发挥所长。 实际上，最好有一组建议的技术，例如特定的 NoSQL 存储或 Web 应用程序框架。

     微服务的缺点包括需要管理越来越多的独立实体、处理更复杂的部署和版本控制。 微服务之间的网络流量以及相应的网络延迟不断增加。 经过大量的讨论之后，粒度服务是性能瓶颈的解决良方。 如果没有工具帮助查看这些依赖性，很难“看到”整个系统。

     标准通过在通信方式上达成共识，以及只关注需要从服务获得什么来使微服务方法奏效，而不是僵化的约定。 必须在设计的初期定义这些约定，因为之后服务将各自独立更新。 在设计微服务方法时出现的另一个描述是“面向服务的精细体系结构 (SOA)”。

     简而言之，微服务设计方法是分离的服务联合，各自独立更改，并达成一致的通信标准。

     随着越来越多云应用的生成，人们发现从长远来看，这种将整体应用分解成独立、方案焦点式服务的做法是较好的方法。

     应用程序开发方法的比较

    

     1) 单一式应用包含域特定的功能，通常按照功能层来划分，例如 Web、业务和数据。

     2) 单一式应用可通过复制到多个服务器/虚拟机/容器上进行扩展。

     3) 微服务应用程序将单个功能分隔成单个较小的服务。

     4) 微服务方法可通过独立部署每个服务而扩展，跨服务器/虚拟机/容器创建这些服务的实例。

     使用微服务方法进行设计并非所有项目的灵丹妙药，但确实更符合前面所述的业务目标。 如果确定以后有机会根据微服务设计重写代码，可以从单一式方法入手。 更常见的是，从单一式应用程序入手，分阶段慢慢分解它（从需要提高可缩放性或敏捷性的功能区域开始）。

     总而言之，微服务方法是以许多小服务来组成应用程序。 这些服务在部署于一组计算机上的容器中运行。 较小的团队可针对方案来开发服务，且每个服务独立进行测试、版本控制、部署和缩放，因此整个应用程序可以得到发展。

      什么是微服务？

     微服务存在多种定义。 如果搜索 Internet，会发现许多有用的资源，这些资源提供了自己的观点和定义。 但在微服务的以下大部分特性上，已广泛达成共识：

• 封装客户方案或业务方案。 要解决什么问题？
• 由小型工程团队开发。
• 使用任何编程语言编写并使用任何框架。
• 由独立控制版本、部署及缩放的代码和（可选）状态组成。
• 通过定义完善的接口和协议来与其他微服务交互。
• 具有用来解析位置的唯一名称 (URL)。
• 在出现故障时可保持一致且可用。

     一言以蔽之：

     微服务应用程序由独立控制版本和可缩放的、以客户为中心的服务组成，这些服务通过标准协议和定义完善的接口彼此通信。

     我们在上一部分已介绍了前两点，接下来进一步澄清其他各要点。

     使用任何编程语言编写并使用任何框架

     作为开发人员，我们应该根据本身的技能或服务需求，自由选择所需的语言或框架。 在某些服务中，可能认为 C++ 的性能优点胜于一切， 而在其他服务中，C# 或 Ja