构建微服务？这是你应该知道的_微服务 royalty-优快云博客

Building Microservices? Here is what you should know | cloudncode

让我们重新回忆一下，微服务体系结构是SOA体系结构的演变，而SOA侧重于各种应用程序的集成，微服务架构（MSA）旨在创建属于单个应用程序的小型模块化服务。

随着高速计算（降低延迟）的出现以及持续部署和集成需求的不断增长，MSA走到了前列。

MSA的另一个经常被忽视的主要优点是，现在独立服务可以用最适合服务的不同语言编写和重写，或者仅仅因为它太过膨胀，否则会引发多年的重写项目……我们都知道这会给我们带来什么。

MSA问题和解决方案

如果这是您第一次使用MSA构建应用程序，或者考虑构建应用程序或只是好奇，那么这些就是我要注意的事项。请注意，下面给出的列表受我的经验限制，并不意味着是一个全面的列表，随着我了解更多，我将不断更新此列表，并在底部对我遗漏的内容发表评论。请注意，这篇文章的目的是作为一个起点来发现所有涉及的内容，对于每个主题，我将建议进行广泛的研究。

1.纳米服务（过度拆分）

当通过MSA构建应用程序时，一个常见的问题是忘乎所以，让服务变得太小，太小以至于许多服务的开销和复杂性开始超过好处，这类服务被称为纳米服务……所以是的，它们是一件坏事。服务应该按垂直功能划分，如计费、支付、预订等，如果您有独立的服务，如“GetUser”和“GetUserById”，那么您就直接进入了纳米服务地狱。极端的例子当然是一种理解工具，现实世界的纳米服务对应用程序的功能是主观的…。。然而，今后要客观。

2.很难跟踪服务URL（服务注册与发现）

当有太多的服务维护其单个地址的配置时，特别是由于其他原因，地址会随着环境的变化而变化，这会让人感到痛苦。现在，您可以使用负载平衡器和类似HAproxy的代理来集中这一点，为了简单起见，我自己做了这一点。然而，负载平衡器只是另一层，它添加了自己的延迟、故障点、如果您有多区域部署（多个数据中心），则需要根据地理位置有效管理DNS交换机等。

那么，如果你不喜欢负载平衡器，你该怎么办？您可以使用一个众所周知的概念“服务发现”。在这个概念中，如果多个环境共享相同的基础设施，那么启动的服务将使用一些基本参数（如环境和应用程序名称）向中央机构注册，并且希望与之连接的应用程序将根据应用程序名称和环境名称轮询一个请求连接的服务等。反过来，该软件还可以确保基本的负载平衡，如在多个服务使用相同参数注册自己的情况下进行循环负载平衡，从而有效地实现直接通信。请看下面的图片以获得相同的插图。

出现的第一个问题是……所以我们用服务发现程序取代了负载平衡器的延迟……公平地说……然而，一般来说，这些软件通常与服务位于同一台机器中，以实现固有的伸缩性和性能，此外，由于它们之间传递的数据相当初级，因此它们使用更快的协议，通常是DNS查询。

请注意，负载平衡器技术也称为“服务器端发现”，我们在这里所说的也被称为“客户端发现”。

优点和缺点

软件世界中的一切都是主观的，脱离了特定用例的上下文，在选择任何模型之前都要考虑其优缺点，这篇文章似乎偏向于客户端发现，只是因为它鲜为人知，适合各种用例。

优势

客户端服务发现或仅服务发现可以减少网络跳跃，并提高系统的整体性能。
上述内容还缓解了对高可用性和高性能负载平衡器系统的需求，如果您在云中，这通常是廉价可用的，例如AWS ELB。

缺点

还有另一个需要学习的软件（Eureka/Consul……随便什么）。
这将客户机与服务注册表耦合，使用Zuul之类的东西（如代理）可以消除此问题，但同时也会降低性能优势。
您必须确保注册中心具有构建服务所用的所有语言/框架的客户端代码。

3.人们在发现服务、可用API以及编写和维护客户端方面存在问题（API接口文档）

使用MSA，系统中引入的一个隐含复杂性是大量服务。如果我们没有很好地记录这些服务，我们也不会欺骗自己，随着时间的推移，会出现许多问题，我注意到的一些问题是：

由于缺乏文档记录，一个实施服务X的团队应该使用团队Y的服务，因此会产生不必要的沟通开销、一般错误，并且通常会抱怨团队Y为什么不太关心他们的截止日期。
没有文档化的服务合同意味着中心人员/小组无法确保所有API都遵循特定标准，导致每个团队甚至同一团队开发不同外观的API合同。
每次在另一个服务中调用服务时，都需要编写与服务集成的管道代码，包括模型、连接器等，如果您是那些超级组织的团队之一，在每次为其他团队使用的每种语言构建服务后都会大量生成客户机，那么请排除此语句。
每次合同稍有更改，都需要通知每个团队新的功能和管道代码需要更新。
每当自动化QA人员需要了解您拥有的20项服务时，他都需要与相关团队坐在一起了解或强迫他们为他制作文档，这将随着合同的更改而重复。
对于那些本质上是公共的服务，文档的测试工具或试用功能（您应该具有）总是滞后于实际的服务合同。

我对此非常固执己见，有时对于这个问题有一个明确的最佳解决方案（无论如何，在撰写本文时）。使用开放API(Home - OpenAPI Initiative)，它是：

Linux基金会下的合作倡议
供应商/语言中立
使用JSON和XML格式定义REST服务的规范，目前还有更多即将推出。
标准化规范旨在为API生态系统构建工具社区。
拥有谷歌、微软、IBM、APIgee、Atlassian等著名成员，请参阅项目网站以获取完整的最新列表。

Open API于2015年11月启动，已经进行了大规模的改编，在撰写本文时，每天有15000次下载。

从SmartBear向组织捐赠Swagger规范开始，Swagger就从1.0发展到2.0，不仅仅是一个自动化的文档工具，更是定义RESTful API的标准方式。后一个事实也意味着Swagger 2.0（或其他当前版本）是开始这项工作的最佳场所。

您可以在一天之内将Open API应用到您的项目中，并对所有现有API的启动和运行进行完整的规范，通常不需要进行进一步的迭代工作。

集成Swagger 2基本上意味着以与WSDL非常相似的标准格式获取API的规范，但这一个规范与供应商和技术无关。由于规范是标准的，它打开了由社区和企业构建的工具世界，这些工具使用try-it功能自动化auto-doc UI（与自定义身份验证一起工作，只需稍作调整），通过几十种格式的命令行生成客户端SDK，生成JMeter管道代码，与一些API网关集成，如APIgee或AWS API网关等等，请查看Swagger@http://swagger.io网站/.

以下是一些参考资料，可以帮助您开始这项工作：

开放API简介Home - OpenAPI Initiative

Swagger网站http://swagger.io网站/

支持Swager的基础设施服务https://github.com/OAI/OpenAPI-Specification/wiki/Sites-and-Services网站与服务

Swagger 2.0规范OpenAPI-Specification/versions/2.0.md at main · OAI/OpenAPI-Specification · GitHub

工具和集成http://swaker.io/开源集成/

用于的Swashbuck。Net Swagger集成GitHub - domaindrivendev/Swashbuckle.WebApi: Seamlessly adds a swagger to WebApi projects!

的AutoRest。根据Swagger规范生成Net SDKGitHub - Azure/autorest: OpenAPI (f.k.a Swagger) Specification code generator. Supports C#, PowerShell, Go, Java, Node.js, TypeScript, Python

Swagger-Codegen用于Java、php等SDK生成GitHub - swagger-api/swagger-codegen: swagger-codegen contains a template-driven engine to generate documentation, API clients and server stubs in different languages by parsing your OpenAPI / Swagger definition.

4、部署作业太多（自动工具化部署）

这是拥有多个服务的固有问题，我希望我能告诉你一些软件可以解决这个问题，但不幸的是，你无法摆脱这个问题。不过，你能做的是使用部署工具，让你的生活更轻松，我一直最喜欢的还是詹金斯@http://jenkins.io（使用基本模板使编写新作业更容易），有一些人最喜欢的beanstalk@http://beanstalkapp.com.

5、一个服务连接失败，一切都失败（单点故障）

随着要使用的所有服务组成的蜘蛛网，失败的可能性增加，处理它们变得更加复杂，当然，也比调用类中的方法更加复杂。幸运的是，MSA并不是一个新事物，有定义良好、经过测试的方法来处理复杂性。连接到其他服务时必须具备的一些功能：

重试次数

最简单的一种方法是，首先在服务调用代码中设置重试逻辑，以防第一次调用失败，可能只有一个服务出现故障，而第二个服务最终将连接到另一个负载平衡服务器或其他任何服务器，请记住以下几点：

固定重试次数：
限制每次个服务重试的超时时间，不要让单次的服务调用使用定义的总超时。
在两次尝试之间进行指数时间后退，例如立即第一次尝试，第二次尝试睡眠10毫秒，第三次尝试睡眠50毫秒。这将确保服务不会开始用轰炸的方式重试正在恢复的服务。

断路器模式

与内存调用不同，服务调用有一个问题，其中的响应更不确定，响应可能需要很长时间才能返回、永久挂起或只是返回错误。在这种情况下，有时会发生这样的情况：如果调用服务等待超时，它将开始耗尽自己的系统资源，例如可用的连接，线程等，并将对自己的调用方响应较慢，导致灾难的级联效应，其中每个服务都会减速，在高流量情况下可能会以级联方式开始失败。

为了避免上述情况，通常使用断路器模式。断路器模式相当简单，在该模式中，代码保留一个计数器，用于记录任何特定服务发生的情况，如果该服务连续返回了阈值数量的错误，则它“打开”电路，并在预定的时间内对同一服务的所有后续请求做快速失败处理，从而为错误的服务提供恢复时间，而不是用更多的消息轰炸它，阻止它再次恢复，通常是通过建立更多的服务器并进行预热。

除了“Closed”（关闭）状态（允许所有内容通过、监视和统计错误）和“Open”（打开）状态（在预设时间之前立即使所有内容失败）之外，在打开状态中花费足够的时间后，还会出现第三种状态“Half-Open”。在半开放状态下，电路允许有限的流量通过以测试水位，如果响应恢复正常，则电路关闭，流量开始流过，如果失败，则电路再次打开。后者是为了确保恢复服务在开始响应时不会立即被请求淹没。

在Java Hysterix中，Netflix OSS的一部分是一个流行的选择@GitHub - Netflix/Hystrix: Hystrix is a latency and fault tolerance library designed to isolate points of access to remote systems, services and 3rd party libraries, stop cascading failure and enable resilience in complex distributed systems where failure is inevitable.

英寸。他正试着那样做。净值@Akka.NET Documentation | Akka.NET Documentation（它是公用事业的一部分）。

6、数据库隔离

写一篇大文章试图在更高层次上涵盖所有内容的动机之一是保持观点的完整性。当我们适应新事物时，往往会与其他事物妥协，数据库是最大的受害者。

在选择MSA时，要记住的主要好处是开发完全独立的、自包含的服务，这意味着其存储技术也是自包含的。有三种方法可以解决这个问题：

每个服务的数据库

最好的答案是，每个服务的数据库允许每个服务都是独立的，可以独立部署，可以为每个服务选择不同的持久性技术（例如用于搜索的弹性搜索）。默认情况下选择此选项。

每个scheme的架构

每个服务一个scheme允许您通过模式清楚地隔离每个服务的数据，并且很容易识别哪些scheme属于哪个服务。

每个服务一些数据库表

有一点是可能的，每个服务都有自己的专用表集，开发过程会保留服务以使用其他服务的表。在我看来，这太难跟上了，选择这种方法只是在开玩笑。

等等，我将如何对跨功能数据进行分组？

查询服务以获取数据并将结果插入到可用的形式中，这就是MSA的全部内容。

数据仓库怎么样？

如果所有数据库都是独立的，并且所有数据库都可以使用不同的技术，我如何获得报告/分析？

数据仓库应该发布自己的契约，并且单个服务应该负责以预期的格式发布数据，而不是将服务的数据库模式绑定到固定的内容。在获取如此大规模数据的流行方法中，有一种方法是将数据事件放入一个队列中，以将数据保存到数据仓库中。

7、每个服务都必须支持所有传输协议和身份验证（网关）

通常要求服务支持各种设备的多种传输协议，AMQP和http是最常见的，然而，所有暴露在互联网上的服务也必须支持身份验证，在很多情况下还必须支持授权。在所有服务中实现此管道代码通常是通过一个公共库来完成的，以减少开发时间，但它有多个缺点，这些缺点起初并不明显（或者至少缺点的严重性并不明显）：

如果这些通用模块中有修8复/增强功能，或者需要支持其他传输，则必须测试和部署所有受影响的服务，而在大多数情况下服务都是受影响的。
MSA的一个主要优点是所有这些服务都是完全独立的，这意味着如果你需要另一种技术，或者如果你想一点一点地转移到另一项技术，你必须重新编码通用模块，然后确保所有服务以完全相同的方式进行身份验证/授权，你的传输协议需始终与每个服务支持的版本同步，例如http 1.0/1.1/2.0或类似版本。
当你暴露在互联网上时，你需要确保你的所有服务都是以标准的方式安全的。

为了解决这个问题，最常见和流行的解决方法是通过API网关，API网关只是一个代理，它知道注册的所有服务的位置，并负责支持所有不同的通信协议，进而将其转换为所有服务都能理解的通用协议，通常是HTTP，但它可以是任何协议。这个网关还负责身份验证和授权，让您的实际服务位于一个封闭的网络中，所有与安全相关的内容都集中在网关本身中。

下图更好地解释了这一点：

由于对这样一个网关的需求，有许多SaaS产品可以为您完成所有这一切，撰写本文时的市场领导者是Mashery@API Management Platform for B2B Enterprise | Boomi是另一个受欢迎的支持开放API@http://apigee.com/关于/，对于AWS部署的解决方案，AWS API网关是另一个解决方案（支持Open API）@API Management - Amazon API Gateway - AWS然而，AWS提供的服务相对较新，但他们经常为其添加新功能，如果您使用AWS作为公共云提供商，请选择此选项。

8.服务器太多，成本太高

一个整体式服务确实会更有效地消耗服务器资源，并且更容易为其编写部署脚本，但是，MSA真正闪耀的地方是通过使用额外的成本来减少日常开发成本和更快的上线时间，这是MSA开始的主要原因之一。

这个问题的基本解决方案是具有良好的可扩展性，即使用较小的机器（越小越好），并在流量开始涌入时添加更多硬件，并在流出时删除多余的节点，使规模尽可能接近实际需求。

然而，有很多方法可以实现弹性，但这取决于您正在部署的位置和正在构建的应用程序类型，我将在下面讨论其中最流行的一种。

在线部署/传统IAAS服务提供商

如果您是本地的，即拥有自己的数据中心，或者如果您使用传统的IAAS服务提供商，该服务提供商需要数周或数天来分配新的服务器、容器是你最好的朋友。如果您可以摆脱虚拟机监控程序层，并且分配新的docker容器很快，并且当前正在成为标准，那么容器无论如何都会使应用程序运行得更快。

有了容器，您可以更好地估计您将拥有的总硬件需求，填充它，分配它，然后根据需要从可用集中分配更多的硬件，同时随着需求的减少而删除它。

公共云，如AWS、Azure…。

如果你在云上……欢迎来到新世界…。。自动扩展是您最好的朋友。如果你已经在这里了，那么你很有可能知道我在说什么，对于那些没有经验的人来说，您可以通过云中虚拟机的映像添加服务器，并根据任何指标/触发器添加或删除服务器，以确保您有足够的硬件以健康的方式满足请求，同时按小时/分钟（取决于哪个云）支付您消耗的资源。

当然，Docker或任何其他容器技术也可以在公共云中使用，但由于您通常无法摆脱hypervisor层，因此容器在云中的好处是有限的。云上的容器对于混合云设置（一些服务器在本地，一些在云上）来说仍然是有意义的，以实现全面统一，但我无法理解其他任何有意义的东西。

公共云中临时调用的服务

如果您的服务偶尔被调用，比如半天没有调用，早上绝对疯狂，晚上相对安静，等等……您可以无服务器……这意味着如果您将AWS API网关和lambda之类的API网关结合起来(What is AWS Lambda? - AWS Lambda)实际上，您根本没有任何服务器……API网关在收到调用时将调用lambda函数，按需启动硬件（在AWS中，我测试它需要大约27ms），运行满足该请求所需的代码，然后关闭硬件。你按100万的使用量付费，你根本不需要维护任何硬件、操作系统、负载平衡器等等。

对于每一毫秒都很重要的以性能为中心的应用程序来说，这不是最佳选择，但对于其他一切来说，它都非常棒。

总结

服务发现（我建议Consul、Eureka和Zuul组合在Java-Spring世界很受欢迎）。
RESTful服务的开放API标准，请查看Swagger 2.0@http://www.swagger.io网站.
了解API网关，在撰写本文时，Mashery是行业领导者，APIgee是另一个受欢迎的选择（与Open API配合良好），如果您在AWS中拥有一切，则AWS API网关（将帮助您实现无服务器化，也可与OpenAPI配合使用）。
了解断路器模式、java世界中的Hystrix（Spring cloud）/Akka.io、中的getAkka.net。网络世界。
用于服务之间交互的队列/服务总线（如果使用AWS，请参阅RabbitMQ、AWS SQS以及其他许多服务）。
想想你是否需要改用演员模型，它增加了复杂性，但对某些人来说很合适。
如果您有一个大型分布式系统，请确保您能够很好地处理日志记录，请查看我写的这篇文章你应该记录什么.