建立一个可伸缩的单块状物
单层或微服务？永恒的问题很多软件工程师在必须设计和部署全新系统时面临。您将找到两种方法的Diehard粉丝。有些人会告诉你巨石是你能拥有的最好的事情，因为它们很容易部署和维护。其他人会声称整料队是“IT恐龙”，并且他们很难规模，看看世界的谷歌，亚马逊和Netflix，它们都使用微服务。事实是，没有“一种尺寸适合所有”解决方案，每个架构都会适应不同的目的，系统和公司。对于谷歌的规模，当然，使用微服务，缩放和维护纪念碑是一个完整的噩梦。然而，对于具有几千用户的应用和平台，巨石可能就足够了。
但我不是在写这个出版物，为巨大或微服务作出争论，而是为了挑战我们的假设并提出以下问题：随着最近的技术进步，我们最终可以设计一个能够支持的“一种尺寸适合所有”建筑亚马逊的规模（好吧，也许亚马逊太多了，让我们考虑松弛），以简单的部署和维护“传统”纪念？
“无论做方面是否严格更好地就没有行业共识。尽管矛盾，但总协议分为两点：
最终超过一些门槛的巨石将被分解。以足够大的规模，只有服务导向的设计是可行的。
只有两个选项。它是面向服务的或一巨石，你必须选择。“
单型是一个服务器端系统，在同一个地方运行一切。单片应用程序通常是启动的单个程序，侦听来自最终用户的网络请求的几个端口，为这些最终用户提供服务，并最终终止。维护基础架构很容易，只是运行应用程序的一个服务器。另一方面，缩放可能很难。一切都处于同一个地方的事实意味着启动应用程序的新副本以扩散它们之间的负载可能导致不一致或无用的冗余。此外，单片应用程序的代码通常在相同的repo中构建，它不会在模块中划分为微服务的情况，每个服务都有自己的回购。如果这是好的或坏的，我没有强烈的意见，但它是它的。单片应用程序的一个例子是我们拥有所有学到的尊重和爱的典型的Django应用程序。
MicroServices架构只是一块被分解成较小块的巨石。而不是拥有负责服务的Django应用程序，而是将REST API与整个系统进行交互，并与您的数据库交谈，您拥有一组服务：用户身份验证的API，服务为服务前端资产，用于处理付款的API，以及它们中的每一个的代码都是方便的结构和维护在自己的回购中。这种替代设计模式背后的推理实际上是非常的声音。通过在许多不同的组件之间分配工作，您将使系统作为一个能够处理更多的请求，而不是当我们粘在一起的地方。然而，通过这样做，我们介绍了更多的复杂性，这需要更多的努力，因此往往更多的人力和更多的钱。管理基础设施是单一大型服务的基础架构不一样，而不是用于小型互连服务（可能分布式）。
“分布式系统是您甚至没有知道的计算机的失败的系统可以呈现自己的计算机无法使用。” - Leslie Lamport.
有些人可能会争辩，“但等一下，这对”传统的“微服务架构来说是有道理的，但无服务器函数呢”。同意，无服务器架构简化了MicroService架构引入的许多复杂性，但它们也引入了新的挑战。您可能获得易于维护的收益可能是由无服务器困难测试的黯淡（现在您不需要测试应用程序的每个服务及其集成，而是每个功能及其集成），潜在的供应商锁定（我们将Docker作为MicroServices作为“标准环境”，但我们没有这一点对于无服务器功能，每个供应商都有自己的要约和工具来管理这个）。无服务器架构正在朝向“一种尺寸适合所有”解决方案，但它们可能还不够。
最后，我们拥有Neo-Monolith方法，它将应用程序划分为在同一基础架构中托管的不同服务（我们获得更清晰的代码结构，并且最终转换到微服务，但具有单片基础设施管理的优势）。
有了这个，我们现在有更清晰的目前景观。关于整料五股的优缺点，已经写了很多。 microServices V.S.无刀。看看这篇文章，或者这一个，或者这一个是关于微服务的优点和缺点的一些有趣的观点。但是我改变了什么，以考虑我们建立更好的架构的能力？
过早地将应用程序转化为一系列服务的问题主要是违反了分布式计算的第1条规则：不要分发您的计算！至少如果你可以以任何方式避免它。
让我重新评估我们建立“一种尺寸”的网络系统架构的三种技术如下：
Web汇编：我对这项新技术的可能性的兴奋，遵循我的出版物的所有人都众所周知。我已经写了大肆宣传为普通字节码，WASM作为Docker替换，并朝着WASM的普遍运行时间。我提到的关于无服务器函数的缺点是缺乏标准运行时环境，但事实是我们可能已经拥有了WASM，并且它可能是新可扩展和可维护架构的关键。实际上，一些速度的公司已经在无服务器提案中使用了WASM。
Web3堆栈：我得到它，我很偏见，但我真的认为Web3协议是互联网的未来，因为我在我的一些出版物中也已经提到了。现在有人希望部署他们的Web平台，需要明智地选择云提供商，他将托管他的基础架构，因为这可能会影响其应用程序的可用性和SLA（以及上述其他问题，例如供应商锁定等问题。）。当实际上，我们将云引用云，因为全局平台能够满足我们所有的计算和连接需求，云是一种能够满足这些需求的脱节组的基础架构提供商组。当我们谈论我们的互联网连接时，我们不关心向我们提供访问权限的ISP，因为互联网已成为一种商品，但云的情况尚未如此。 WEB3堆栈协议和互联网的权力下放是最终将云变为商品的原因。我的感觉是，商品化云最终会给我们带来我们正在寻找的“一种尺寸适合所有”架构，因为它将被“新互联网”默认支持。
亚坏常规：Atmo可以轻松创建强大的服务器应用程序，而无需担心可扩展性，基础架构或复杂网络。 ATMO使您可以使用各种语言编写名为Runnables的小型自包含函数，并通过声明方式编写它们来定义业务逻辑。然后，atmo自动缩放一个平面的实例网络，以处理使用其网格消息总线和嵌入的作业调度程序来处理流量。 Atmo可以处理基于请求的流量，很快就可以处理来自像Kafka或EventBridge等各种系统的事件。所以基本上，您部署了一个无服务器的基础架构，仿佛它是一巨石。我已经滋补了Atmo，它的底层模块现在几个星期了几个星期，我认为这是一个很好的技术，以及一个良好的例子，这是如何在分散的云上的“一种尺寸适合所有”解决方案。我不会深入了解atmo工作（至少现在），但我强烈推荐给它一个好的外观，并检查出这个问题;）（这可能是大的东西的开始吗？）
如果Monoliths难以规模，微服务太复杂，那么您如何设计一个可以与您的流量和开发团队一起扩展的系统，而不会成为操作，维护和扩展其功能的痛苦？在过去的几年里，很明显需要中间地面。我不希望这个解决方案为每个人工作，但大多数产品都没有提供真正使得MicroService努力值得它的流量。 - @coohix.
在我的尺寸在几周前，我提到我提到我为Hackathon建立了一个概念证明，我如何想象于IPFS的计算将有效（你可以在这里看看代码）。这个想法已经瞥了一眼全球云如何看起来像。您在网络中运行计算，而无需担心谁运行它，或者资源的位置。当然，没有一个无数的模型，因为没有激励系统，没有奖励同行奖励他们的资源以保持网络运行的激励系统（特别是如果我们想要SLA和某些保证，但是现在让我们离开这张照片）。
使用分散的网络已经成为IPFS已经到位，为什么不试图为开发人员提供托管应用程序的可扩展设计，易于维护？ IPFS是一个分散的内容可寻址网络，因此它具有CDN功能的设计。寻求运行一些作业（或获取一些文件）的同行将从其最近的邻居（如果可能）获取它，而无需担心查找托管服务的服务器，因为内容解决网络中的资源无关。所有这些概念都可能使“整体五”制作。 microServices“Argument过时了。实际上，差不多年前我已经编写了一个出版物，解释了最近的诸如网络邮票的标准是如何完美适合内容可寻址网络。
更改互联网工作的核心方式可以使十年的旧参数过时，例如架构战争，它一切都是通过将云作为单个全局实体公开的协议的“实际”商品化，而不是脱节在不同的提供者之间争取。采用是这种改变的关键，以成为现实的这种变化。所有这一切都应转化为开发人员和用户的更好的替代方案。 Atmo对IPF可以成为这个“革命”的开始。我们拭目以待…