软件体系结构是用于软件系统开发和实施的高级结构。随着软件变得越来越普及，不同的体系结构风格随之发展。在这种形势下，微服务架构获得了很大的吸引力和相关性。
什么是微服务？
微服务（也称为微服务体系结构）是一种架构样式，将应用程序构造为一组松散耦合的服务，每种服务均实现业务功能。微服务架构可实现大型复杂应用程序的持续交付和部署。它还使组织能够随着时间的推移改进技术堆栈，扩展规模变得更具弹性。微服务架构提倡将单个应用程序开发为松散关联的服务的集合。这些单元还可以连续地交付和部署大型单片应用程序，而且不需要集中化。
为什么选择微服务？
要了解微服务的普及需要了解单片应用程序。任何应用程序都将包含一个客户端接口、一个用于存储和处理数据的数据库以及服务器端逻辑。整体应用程序作为一个单元构建。在单片应用程序中，服务器端逻辑以单片形式捆绑在一起，所有用于处理请求的逻辑都在单个进程中运行。此系统的所有更新都需要部署新版本的服务器端应用程序。在单片应用程序中，任何修改都与整个变更周期相关联，并且这些周期总是相互关联。由于团队必须扩展整个应用程序，因此也不可能对特定功能和模块进行粒度扩展。
为了克服管理、更新和部署应用程序（尤其是在云上）日益增长的复杂性，微服务架构的采用开始兴起。每个微服务都定义了一个特定的业务功能，并且只定义了与该功能相关的操作，所以非常轻量级和具有可移植。微服务可以在较小的主机中部署和运行，而不必使用传统体系结构的RAM和CPU资源。
与SOA的区别
逻辑上分离应用程序中的功能单元不是一个新概念。最常见的比较形式是微服务和面向服务的体系结构（SOA）之间的比较，微服务和SOA在很多方面都存在差异。SOA在接口级别工作，目的是将功能公开为服务接口。这些接口使下一代应用程序使用数据和操作变得更加容易。SOA的范围是围绕应用程序之间接口的标准化，而微服务具有应用程序级别的范围。
微服务的缺点
与任何架构风格一样，微服务也有一些缺点。其中一个大问题是将应用程序的整个业务功能分解为多个粒度的单元，其中围绕子业务单元划分界限很困难，边界定义不当可能会对扩展应用程序产生负面影响。在不同的服务之间重用代码也很困难，特别是在基于不同语言构建的代码上。跟踪运行各种服务的主机可能很繁琐，并且导致各个组件组合在一起而造成混乱和资源浪费。微服务架构还需要有效的技术技能，对于习惯于传统形式的应用程序工程的开发人员来说，这是一个巨大的转变。
容器如何提供帮助？
微服务架构的采用导致需要克服一些缺点。这推动了容器生态系统的兴起。容器是操作服务虚拟化的一种形式，它允许各种服务在与资源无关的单元中运行。Linux容器使用内核接口。内核是操作系统的核心计算机程序，是在启动时加载的第一个程序。
容器的配置允许多个容器共享相同的内核，同时运行，并且相互独立。操作系统虚拟化使代码的传输和部署效率更加高效，甚至比虚拟化硬件的传统虚拟机（VM）更高效。Docker是最流行的容器技术，它已经成为标准的基于Linux内核的容器，并且短时间内被数千个应用程序所使用。同一主机的容器之间的独立性使得部署基于不同技术和框架的微服务变得非常简单和直接，容器的可移植性和轻巧性也是微服务部署的必备之选。为了解决微服务管理的问题，已经出现了各种容器管理系统来更好地管理和协调这些容器，以及配置和管理整个集群服务器。
API的作用
我们知道微服务是组成大型应用程序的独立维护的组件。我们也知道容器是部署它们的好方法。微服务和容器使用进程间通信（IPC）机制进行交互。这些交互可以是：
一对一，客户端请求由一个服务处理
一对多，客户端请求由多种服务处理
如果IPC机制涉及请求-响应周期，则最常用的通信方式是RESTful，几乎总是使用HTTP / JSON API。微服务之间用作IPC的API与传统形式不同。这些API更精细。由于暴露微服务的API会暴露数据，因此客户端可能必须遵循服务之间的一对多交互形式才能获得所需的数据。
例如，假设你正在按照微服务模式构建电子商务网站。销售产品的全貌可以通过多种服务绘制，例如用于公开基本产品信息的服务，如：标题和描述、公开价格的服务、导出评论的服务等等。希望获得产品完整数据的用户现在必须请求所有这些服务。在多设备生态系统中，不同的设备可能需要不同的数据，例如台式机应用程序可能需要比移动版本更复杂的数据。
微服务的设计优先方法
我们已经讨论了API如何成为各种服务相互通信的最常见方式。为了更好地通过API公开服务，需要提供这些API的通用接口，用来准确告知每个服务应该做什么。此接口是定义客户端和服务之间SLA的契约。微服务架构主要是企业级的运动，因此，为暴露微服务数据的api提供一流的处理非常重要。许多组织采用了“设计优先”的构建微服务的方法，该方法包括首先设计和定义微服务的接口，检查并稳定该协议，然后才实现服务。在进行任何实际开发之前，“设计优先”方法可确保服务符合用户的要求。以下是对API采用“设计优先”（或“ API优先”）方法的一些主要注意事项：
加快上市速度
就其本质而言，微服务是内部的，意味着具有最小的计算能力和使用时间。这同样适用于公开它们的API。因此，自动化这些API的设计、文档和开发以实现快速的API交付速度非常重要。接口不仅定义了客户端和服务之间的公共SLA，而且还允许生成服务器和客户端模板以及测试用例，从而使开发和测试变得更加容易。诸如Eolinker之类的专业工具提供了用于设计的API编辑器，可以帮助实现API的快速上市速度。
灵活的编排
细化公开微服务的API，这意味着需要特定实体数据的客户端应用程序总是需要调用多个API。在基于微服务的应用程序中处理数据交换的复杂性是一个巨大的问题。 处理多个服务请求的解决方案是实现API网关，网关可以通过单个入口点处理请求。通过API网关有效地从设计阶段过渡到部署阶段变得非常容易。Eolinker网关是为希望有效地编排这些请求设计的。
负责任的设计
多个团队构建不同的服务可能会很棘手。不仅管理人力资源很困难，当这些团队开始开发服务接口时，而且会变得更加复杂。当多个团队定义和构建RESTful接口时，URL结构、响应头和请求-响应周期对象中的设计模式存在差异。由于接口定义了客户端和服务之间的交互方式，因此设计上的差异会导致服务开发阶段混乱和额外开销。修复这些问题只会导致时间、金钱和人力资本等形式的资源消耗。 可以使用Eolinker设计功能来克服这些问题，API文档模板可确保RESTful接口符合团队需求的标准蓝图。在数据结构中，可以存储通用的、可重用的语法，这些语法可以多个API中快速引用。API文档模板和数据结构可在构建服务IPC时确保设计一致性和快速上市时间。
如需了解更多API与微服务内容，请访问：www.eolinker.com