游戏 服务器 微服务

介绍

刚开始时，由于要求简单，所以应用程序既简单又小。 随着时间的要求和需求的增长，我们的应用程序变得越来越大，越来越复杂。 这就导致了将单片服务器开发和部署为一个单元。 在某种程度上，微服务可以通过简单的应用程序回归基础，这些应用程序可以通过利用彼此之间的API一起工作来满足当今对复杂性的需求。

什么是整体服务器？

与微服务相比，微服务最好被解释。 整体服务器 。 它们作为单个单元开发和部署 。 对于Java，最终结果通常是单个WAR或JAR文件。 C ++ 、. Net，Scala和许多其他编程语言也是如此。

大多数软件开发的短暂历史都以我们开发的应用程序规模的不断增加为标志。 随着时间的流逝，我们将越来越多地添加到我们的应用程序中，从而不断增加它们的复杂性和大小，并降低我们的开发，测试和部署速度 。

随着时间的流逝，我们开始将应用程序划分为多个层：表示层，业务层，数据访问层等。这种分离比物理上更逻辑。 虽然开发变得容易一些，但每次更改或发布时，我们仍然需要测试和部署所有内容。 在企业环境中，拥有花费数小时才能构建和部署的应用程序并不少见。 测试，尤其是回归测试，往往是一场噩梦，在某些情况下会持续数月之久。 随着时间的流逝，我们进行仅影响一个模块的更改的能力正在下降。 层的主要目的是使它们易于替换或升级。 这个承诺从未真正兑现。 在大型整体应用中更换零件几乎从来都不容易，而且没有风险。

扩展此类服务器意味着扩展整个应用程序，从而产生非常不平衡的资源利用。 如果我们需要更多的资源，即使瓶颈是一个模块，我们也被迫在新服务器上复制所有内容。

什么是微服务？

微服务是一种架构和开发由小型服务组成的单个应用程序的方法。 了解微服务的关键是它们的独立性 。 彼此分别开发，测试和部署。 每个服务作为单独的进程运行。 不同微服务之间的唯一关系是通过它们公开的API来完成数据交换。 它们以某种方式继承了Unix / Linux中使用的小型程序和管道的思想。 大多数Linux程序很小，并且会产生一些输出。 该输出可以作为输入传递给其他程序。 链接在一起时，这些程序可以执行非常复杂的操作。 它是由许多简单单元组合而成的复杂性。

微服务的关键方面是：

• 他们做一件事或负责一项功能。
• 每个微服务都可以通过任何一组工具或语言来构建，因为它们彼此独立。
• 由于每个微服务在物理上是彼此分离的，因此它们实际上是松散耦合的。
• 开发不同的微服务的不同团队之间的相对独立性（假设它们公开的API是预先定义的）。
• 简化测试以及持续交付或部署

微服务的问题之一是决定何时使用它们。 最初，尽管应用程序仍然很小，但微服务试图解决的问题并不存在。 但是，一旦应用程序增长并且可以提出微服务的理由，切换到其他体系结构样式的成本可能会太大。 经验丰富的团队可能从一开始就使用微服务，因为他们知道，他们以后可能需要偿还的技术债务比使用微服务要昂贵得多。 通常，就像Netflix，eBay和Amazon一样，整体式应用程序开始逐渐向微服务发展。 新模块被开发为微服务，并与系统的其余部分集成。 一旦证明了自己的价值，现有的整体应用程序的一部分就会重构为微服务。

企业应用程序开发人员最经常批评的一件事是数据存储的分散化。 尽管微服务可以使用集中式数据存储来工作（只需进行少量调整），但至少应该探索使该部分分散的选项。 可以将与某些服务相关的数据存储在单独的（分散式）存储中，然后将所有数据打包到同一容器中，这比在集中式数据库中存储这些数据更好。 我们不建议始终使用分散存储，而在设计微服务时考虑使用该选项。

缺点

运营和部署复杂性增加

反对微服务的主要论点是操作和部署的复杂性增加。 这种说法是正确的，但是由于有了相对较新的工具，它可以缓解。 配置管理（CM）工具可以相对轻松地处理环境设置和部署。 Docker对容器的利用大大减少了微服务可能引起的部署麻烦。 CM工具与Docker一起使我们能够轻松部署和扩展微服务。 可以在文章连续部署：使用Ansible和Docker实施中找到一个示例。

在我看来，增加部署复杂性的争论通常没有考虑到我们在过去几年中看到的进步，并且被大大夸大了。 这并不意味着一部分工作不会从开发转移到DevOps 。 肯定是。 但是，在许多情况下，收益要大于转移带来的不便。

远程过程调用

另一个反论点是远程进程调用会降低性能。 通过类和方法的内部调用更快，并且无法解决此问题。 性能损失对系统的影响取决于具体情况。 重要的因素是我们如何分割我们的系统。 如果我们将非常小的微服务带到了极致（有些人建议它们的LOC不应超过10-100 LOC），那么这种影响可能是相当大的。 我喜欢创建围绕用户，购物车，产品等功能组织的微服务。这减少了远程流程调用的数量。 另外，必须注意的是，如果从一个微服务到另一微服务的呼叫正在通过快速内部LAN进行，则负面影响相对较小。

优点

以下仅是微服务可以带来的一些优势。 这并不意味着在其他类型的架构中不存在相同的优势，而是与微服务相比，与其他选项相比，它们可能会更加突出。

缩放比例

扩展微服务比单片应用程序容易得多。 在后一种情况下，我们将整个应用程序复制到一台新机器上，而在微服务中，我们仅复制那些需要扩展的服务 。 我们不仅可以扩展需要扩展的内容，而且可以更好地分发内容。 例如，我们可以将一个CPU利用率很高的服务与另一个使用大量RAM的服务放在一起，同时将第二个CPU需求服务移至其他硬件。

革新

一旦建立了初始架构，单片服务器就不会留出太多的创新空间。 由于其性质，更改事物会花费时间，并且实验非常冒险，因为它可能影响所有事物。 例如，不能仅仅因为它更适合一个特定的模块而更改Apache Tomcat for NodeJS。

我并不是建议我们应该为每个模块更改编程语言，服务器，持久性等。 但是，单片服务器趋向于相反的极端，在这种极端情况下，即使不是不受欢迎的更改也会带来风险。 通过微服务，我们可以分别为每个服务选择我们认为是最佳解决方案的解决方案 。 一个可能使用Apache Tomcat，而另一个可能使用NodeJS。 一个可以用Java编写，另一个可以用Scala编写。 我并不是在提倡每种服务都与其他服务有所不同，但是可以按照我们认为最适合当前目标的方式来进行每种服务。 最重要的是，更改和实验要容易得多。 毕竟，只要尊重API，我们所做的一切只会影响众多微服务中的一个，而不会影响整个系统。

尺寸

由于微服务很小，因此更容易理解。 查看一个微服务正在做什么的代码要少得多。 这本身就极大地简化了开发，尤其是当新来者加入该项目时。 最重要的是，其他所有东西都趋向于更快。 与整体应用程序中使用的大型项目相比， IDE在小型项目中的运行速度更快 。 由于没有大型服务器或大量库可供加载，因此启动速度更快 。

部署，回滚和故障隔离

部署更快，更容易 。 部署小项目总是比部署大项目更快（如果不是更容易的话）。 如果我们意识到存在问题，则该问题的影响可能有限，并且可以更轻松地回滚 。 在回滚之前， 故障只隔离到系统的一小部分。 连续交付或部署可以用大型服务器无法实现的速度和频率来完成。

无需长期承诺

整体应用程序的常见问题之一是承诺。 我们经常被迫从一开始就选择会持续很长时间的体系结构和技术。 毕竟，我们正在建立一个可以持续很长时间的大型项目。 对于微服务而言， 需要长期的承诺并没有那么大 。 在一种微服务中更改编程语言，如果发现它是一个不错的选择，则将其应用于其他微服务。 如果实验失败或不是最佳方案，则仅需要重做系统的一小部分。 同样适用于框架，库，服务器等。我们甚至可以使用不同的数据库。 如果某些轻量级NoSQL似乎最适合特定的微服务，为什么不使用它并将其打包在容器中？

最佳实践

以下大多数最佳实践通常都可以应用于面向服务的体系结构。 但是，使用微服务，它们变得更加重要或有益。

货柜

处理许多微服务很容易成为一项非常复杂的工作。 每个都可以用不同的编程语言编写，可以要求不同的服务器（希望是轻量级的）或可以使用不同的库集。 如果将每个服务打包为一个容器，那么大多数问题都会消失。 我们要做的就是使用Docker等运行容器，并相信所需的一切都在容器内部。

代理微服务或API网关

大型企业前端可能需要调用数十甚至数百个HTTP请求（与Amazon.com一样 ）。 与接收响应数据相比，调用请求通常花费更多时间。 在这种情况下，代理微服务可能会有所帮助。 他们的目标是调用不同的微服务并返回聚合的服务。 它们不应包含任何逻辑，而只是将多个响应分组在一起，并以汇总数据响应给消费者。

反向代理

切勿直接公开微服务API。 如果没有某种类型的编排，则消费者与微服务之间的依赖关系变得如此之大，以至于它可能消除了微服务应该给我们的自由。 诸如nginx和Apache Tomcat之类的轻量级服务器非常擅长执行反向代理任务，并且只需很少的开销即可轻松使用。 请查阅《 持续部署：实施 》一文，以了解将反向代理与Docker和其他一些工具结合使用的一种可能方式。

极简主义方法

微服务应仅包含它们真正需要的包，库和框架。 它们越小越好。 这与单片应用程序中使用的方法形成了鲜明对比。 以前，我们可能曾经使用过像JBoss这样的JEE服务器，它包装了我们可能需要或可能不需要的所有工具，而微服务最适合使用更简单的解决方案。 拥有数百个微服务，每个微服务都具有完整的JBoss服务器，这显得过分了。 例如， Apache Tomcat是一个更好的选择。 我倾向于使用更小的解决方案，例如，将Spray作为一种非常轻巧的RESTful API服务器。 不要打包您不需要的东西。

同样的方法也应应用于操作系统级别。 如果我们将微服务部署为Docker容器，那么CoreOS可能是比Red Hat或Ubuntu更好的解决方案。 它摆脱了我们不需要让我们更好地利用资源的事情。

必须进行配置管理

随着微服务数量的增长，对配置管理（CM）的需求也在增加。 不用工具如Puppet ， Chef或Ansible （仅举几例）部署许多微服务很快就成为噩梦。 实际上，无论有没有微服务，对于最简单的解决方案不使用CM工具都是一种浪费。

跨职能团队

虽然没有规定使用哪种类型的团队的规则，但是当团队中的团队是多功能的时，微服务才是最好的选择。 从开始（设计）到完成（部署和维护），应由一个团队负责。 它们太小，无法从一个团队转移到另一个团队（架构/设计，开发，测试，部署和维护团队）。 最好有一个负责微服务整个生命周期的团队。 在许多情况下，一个团队可能负责多个微服务，但多个团队不应该一个。

API版本控制

版本控制应适用于任何API，微服务也是如此。 如果某些更改会使API格式失效，则该更改应作为单独的版本发布。 对于公共API或微服务，我们无法确定谁在使用它们，因此必须保持向后兼容性，或者至少要给消费者足够的时间来适应。 REST API with JSON文章中发布了有关API版本控制的部分。

摘要

微服务并不能解决我们所有的问题。 没有什么是。 它们不是所有应用程序都应创建的方式。 没有适合所有情况的单一解决方案。

微服务已经存在了很长时间，近年来，它们的普及程度也在不断提高。 导致这一趋势的因素很多，可伸缩性可能是最重要的。 新工具（尤其是Docker）的出现使我们能够从新的角度看待微服务，并消除了其开发和部署所造成的部分问题。 诸如Amazon，NetFlix，eBay等“大公司”对微服务的利用，提供了足够的信心，即企业应用程序开发人员已可以评估（如果不使用）这种体系结构样式。

翻译自: https://www.javacodegeeks.com/2015/01/monolithic-servers-vs-microservices.html

游戏 服务器 微服务