在上一篇文章中，我们讨论了云服务如何成为提供IT服务的不成文标准。 很容易猜到，想要继续在用户应用程序上赚钱的公司，必须考虑到Cloud-Native的方法来适应并创造新产品。 但是，对于开发人员而言，这绝对是个好消息，因为使用云技术为他们带来了巨大的新机会。 最主要的是能够正确处理它们。
当应用程序订购环境时
如果您已经阅读了云技术
指南 ，则可能会记得虚拟化技术是云的“魔术来源”之一。 因此，开发人员实际上不需要考虑将在其上运行应用程序的服务器的参数。 如果正确配置的虚拟机管理程序或容器可以配置具有应用程序需要工作的几乎所有特征的计算机，为什么还要花时间？
这种想法的发展是基础架构即代码（IAC）方法。 其实质是使开发人员或运营服务能够使用与开发阶段维护基础结构相同的方法。 它使您可以预先准备通用软件控制单元，并将这些组件轻松集成到新项目中。
现代数据中心的功能已经使我们能够继续使用声明性语言进行基础架构管理。 理想情况下，应用程序应该管理它在数据中心中占用的资源池。 当需要提前订购和设计，或者在不同项目中重复使用相同的基础结构组件时，这将使开发人员不会陷入与基础结构工作过程相关的限制。
实际上，开发人员或工程师发出“拉取请求”，其中包含虚拟机的配置（内核，内存，网络，模板等），然后虚拟环境管理器根据中的设置独立创建计算机或创建新的数据库实例或启动预安装的服务。文件。 当使用大数据和神经网络时，这种方法才是真正的救星。 在某些情况下，与这些技术相关的应用程序需要动态更改内存和处理器的电量。
例如，要训练网络，有必要通过它“驱动”数百GB的信息，而云使得有可能根据请求获得所需的容量。 培训完成后，资源将返回到提供者池，并且开发人员无需考虑如何使用它们或如何以其他方式配置应用程序，从而继续以较低的容量工作。
独石vs. 有序的混乱
由于云可以灵活地适应开发人员的需求，因此从理论上讲，这简化了另一个任务-扩展应用程序的问题。 理论上为什么呢？
不幸的是，扩展应用程序的任务不是线性的。 为了使应用程序在高峰出勤（或计算）期间应对巨大的负载，仅为其提供额外的内存和处理器功能是不够的。 绝对每个传统应用程序都有一个阈值，在此阈值之后，它就不再能够“消化”新资源并显示出性能提升。 在这种情况下，问题不是资源，而是大多数程序的体系结构。
对于具有单片架构的应用程序来说，这个问题尤其严重，实际上它是单个二进制文件。 这种方法的优势显而易见：单片应用非常简单且线性。 可以预测，跟踪和调试所有用户行为方案。
然而，这种简单性是有代价的。 首先，这些是上述缩放的问题。 在某个时候，即使是最周到的整体应用程序也无法从升级到运行该服务器的服务器配置中更有效地工作。
其次，单片应用程序不太容易转移到新服务器，这可能需要对程序进行完全重新编译。
第三，这种应用程序难以维护和开发。 任何更新都需要完整组装整个程序，并且其中一个代码块中的错误可能导致整个系统崩溃。
为了寻求有关如何解决这些问题的想法，开发了另一个概念-面向服务的体系结构（SOA）。 这意味着该应用程序分为几个模块，每个模块都为其他模块提供某种功能。 这些模块通过一组Web服务相互交互，并且可以独立访问一个或它们自己的数据库。
这种方法确实简化了程序的支持，并且不会将其更新“转化为操作者的工作”，在程序中没有出错的余地。 但他也有缺点。 关键之一是扩展此类应用程序的开发问题。 随着程序的发展，将新功能“推入”最初由架构师批准的5-10包变得越来越困难。 他们的人数在增加，这在支持方面变成了问题。
微服务是应用程序发展的要素
SOA演进的结果是微服务架构的思想，该思想被用于云应用程序的设计中。 从概念上讲，这两种方法的思想极为相似，并且某些架构师甚至认为微服务体系结构是SOA的特例，甚至没有将微服务体系结构选为单独的范例。
微服务架构意味着该应用程序不是由少数几个大型模块组成，而是由许多独立的部分组成。 与整体组件不同，在微服务应用程序中，可以使用各种方法来使组件彼此交互。 系统没有单一的预定状态。 相反，每个组件都“根据情况”工作：一旦收到事件，便开始工作。 这允许非常灵活和独立的体系结构。
同时，微服务应用程序中服务的数量不断变化-添加了一些，删除了一些。 在新方法中，可以替换任何微服务，而可以在其中嵌入一系列微服务。 由于其他服务没有直接关系，因此它们继续稳定工作。 这是程序的自然演变。 因此，开发人员和架构师有机会快速更改某些内容，以响应业务需求的变化并超越竞争对手。
除了提高更新更新的速度之外，微服务体系结构的使用还允许分散管理。 负责服务开发的团队有权确定其内部体系结构和功能。 顺便说一下，这种方法现在由Sberbank建筑委员会在Technology Block中实施。
同时，坐下来开发您的云应用程序时，您不应该急于将其迅速粉碎成其组成元素。 这种思想不周全的方法的主要对手是马丁·福勒。 他是微服务架构思想的作者之一。 最初使用整体方法比较容易，然后以“自然方式”刺激应用程序的发展，重点放在瓶颈的分解和附加功能的添加上。
结果，我们可以制定以下规则：使用微服务体系结构时，程序员的任务不仅是将应用程序分解为最大数量的组件，而且还故意区分它们在接收和处理数据方面的责任。
四个细节
除了许多明显的优点之外，微服务体系结构还具有其自身的特征，在开发云应用程序时必须将其考虑在内。 特别是，为了支持此类应用程序的运行，有必要不断维护对内部API的管理质量的更高要求。
当组件之一更改其接口时，它必须支持向后兼容，以便支持其自己的API的先前版本。 如果遵守此规则，则可以从旧版本动态切换到新版本，而不会失败。 如果无法解决对先前版本API的支持，那么这充其量只会威胁到部分应用程序功能的丧失，最坏的情况是它的操作会永久崩溃。
微服务应用程序的第二个重要功能是难以在其中找到错误。 如果用单片逻辑或SOA编写的应用程序崩溃，将不难找到问题的根源。 在包含许多服务的应用程序中，由于来自用户的数据通常会通过多个微服务，因此很难确定错误原因，因此很难确定其中哪一个崩溃了。 同时，必须非常仔细地执行错误搜索过程：任何不成功的重构都可能导致工作模块崩溃，并且除了最初的问题之外，开发人员还将获得第二个问题。
开发云应用程序时必须考虑的第三个重要细节是其组件相互交互的方式。 与SOA中一样，服务使用Web服务交换数据，但是微服务体系结构中已经出现了交互模式，例如流，CQRS，事件源。 通常，开发人员期望请求与应用程序中响应之间的响应时间非常短。 在分布式系统中，人们甚至不能完全依赖答案将完全存在的事实。
同样，在云应用程序的体系结构中，微服务使用最适合解决其特定问题的各种数据库。 例如，网格可以快速读取，但是几乎不能应付大量的数据更改操作。 这样的基础非常适合维护存款帐户-它们很少改变。 另一种操作是处理。 每天每张地图上都会有数十种变化，相反，数据读取很少。
最后，在开发云应用程序时需要记住的第四个事实是，微服务体系结构主要集中在无状态服务的使用上。 在这种情况下，请不要极端。 如果业务逻辑需要，某些服务（如有必要）仍可以提供状态支持，并且在设计时必须格外小心。
例如：如果用户提出贷款请求，则接收到该应用程序的系统必须保存此状态才能将其转移到其他服务。 但是负责在信用历史记录的内部文件中查找信息的服务可能无法保存其状态，而不会忘记几分钟前查找的姓名用户的数据-无论如何，稍后会收到新请求（尽管在此过程中可能会是不同的服务行为）。
上面描述的所有示例和实践已被全球IT行业的领导者积极使用。 例如，Netflix是微服务架构开发的先驱。 该公司已经发布了许多开源应用程序，库以及用于监视，平衡和记录正在运行的微服务应用程序的框架。