可帮助大型企业加快开发，部署和扩展的微服务模式
摘要
通过这些有用的微服务模式，可以提高团队的工作效率和代码的可靠性。
这是关于微服务模式和反模式的两部分系列文章的第一篇。 在本文中，我们将重点介绍一些有用的模式，这些模式在被利用时可以加速开发，部署和扩展。 在下一篇文章中，我们将重点讨论微服务模式如何变得有毒，导致更多的开销和可靠性以及变得难以管理的混乱。微服务模式假定了大规模的企业风格环境。 如果仅使用少量服务（1到5），您将不会像拥有10、100或1000多个服务的组织那样感受到积极的影响。 对于初创企业和较小的项目，我最大的模式是不要为复杂性而考虑过多并增加复杂性。 模式旨在帮助解决问题，它们不是锤击工程团队的锤子。 因此，请牢记这一点。
打开扩展，关闭修改
我们将以原则而非模式开始我们的模式讨论。 与微服务相比，从事微服务的软件开发团队从这一原则中获得了更多的收益。 这是罗伯特·C·马丁（鲍勃叔叔）的SOLID原理的经典模式。
简而言之，为扩展而开放，为修改而封闭意味着打开代码以通过继承添加新功能，而为直接修改而封闭。 我的定义较为宽松，往往更为实用。 我的定义是“不要破坏现有合同”。 添加方法很好，但不要更改现有方法的签名。 您也不应更改已建立方法的功能。
为什么这种模式在微服务中如此强大？
当您有不同的团队从事不同的服务，而这些服务必须相互协作时，则需要一定程度的可靠性。 我作为服务的使用者，即使添加了新功能，将来也需要能够依赖该服务。
我们如何体现这种模式？
简单。 不要违约。 永远没有充分的理由中断现有的生产合同。 但是，可能有很多很好的理由要添加它，从而使它“可以扩展，可以关闭以进行修改”。 例如，如果您必须开始收集新数据作为服务的一部分，请添加新的终结点并设置时间线以折旧服务调用，但不要在一个步骤中同时进行这两个操作。 与数据管理类似：如果需要重命名数据列，只需添加一个新列并将旧列留空一段时间。 当您对旧服务进行折旧时，现在是进行与该折旧相关的所有清理工作的好时机。 如果您可以坚持这一原则，则组织中每个拥有良好开发经验的人。
模式：具有SPA网关的企业服务
当我们开始构建大型应用程序并转向微服务范式时，可管理性问题Swift浮出水面。 我们必须从多个层面解决可管理性，还必须考虑依赖管理。 微服务很快就会变成紧密联系在一起的依赖关系。 我们创建一个“泥石流”，而不是拥有一个整体的“大泥球”。
解决这些问题的一种方法是引入企业域服务的概念，该概念负责组织中不同域内的任务，然后将特定于域的逻辑组合到单页中更有意义的活动（即产品功能）中。应用程序（SPA）网关层。 SPA网关用于获取应用程序整体功能的某些子集（即，单页价值）并整理功能，将“硬部分”（持久性，状态管理，第三方调用等）委派给关联的企业服务。 在这种模式下，每个企业服务都将自己的数据作为单个数据库，数据库的集合或作为拥有的模式（作为大型企业数据库的一部分）拥有。
模式：具有网关和ETL的SPA服务
现在，我们将稍微增加复杂度。 人们在开始使用微服务时会遇到的主要问题之一是：“我如何加入复杂数据？” 在上面的带有SPA网关的企业服务示例中，您只需调用多个服务即可。 当您合并两到三个数据点时，这很好，但是当您需要真正深入的问题回答时，该怎么办？ 例如，您如何查找某个地区的客户的所有人口统计数据，这些客户在一个月的第二季度获得了绿色版本的发票？
如果您将所有数据都放在一个数据库中，那么这个问题并不是很难解决。 但是您可能很快就开始违反单一责任原则。 然后，这里的目标是将这种责任委托给真正擅长仅通过ETL（提取，转换，加载）联接数据的服务。 ETL是数据仓库的一种模式，您可以从不同的数据源中提取数据，将数据转换为对业务有意义的东西，然后将转换后的数据加载到其他地方以进行利用。 拥有将问这些类型的人口统计问题的域的拥有团队将负责照料和提供执行ETL的服务，存储已转换数据的数据库或架构以及提供访问权限的服务对它。
为什么不只是在数据库上进行多域调用？
这是一个公平的问题，在一个小型项目中，这样做可能是合理的。 但是，在具有大量活动部件的大型项目中，每个部件都必须能够独立移动。 如果我们直接在数据库级别进行组合，则可以保证数据只能在单个数据库上一起传输，而处理少量数据则没什么大不了的。 但是，一旦我们开始处理数十，数百或数千TB的数据，这将变得非常重要，因为它将极大地影响我们独立扩展域的方式。 使用ETL和数据仓库策略为数据的移动和组合提供抽象层时，如果我们移动数据，可能需要我们更新ETL。 但是，与试图在每个域中解开成千上万个嵌套的存储过程相比，此功能更易于管理。
总结思想
请记住，这些只是一些可用的模式。 您的目标是解决问题，而不是制造更多问题。 如果某个特定的模式不能很好地满足您的目的，则可以创建自己的模式或混合搭配。
处理具有多个域的大型项目的最简单方法之一是使用具有自动映射功能的AppDynamics之类的工具，以更好地理解依赖关系图。 这将帮助您理清电线的缠结。
请记住，吃大象的最佳方法是一次咬一口。
在我的下一个博客中，我们将介绍一些常见的反模式，这些反模式一开始似乎是非常好的主意。 但是反模式可能会很快导致问题，并且难以扩展和维护您的项目。
翻译自: https://www.javacodegeeks.com/2018/09/microservice-patterns-deployment-extension.html