如何简化宏运算?_简化从宏服务到微服务的过渡

如何简化宏运算?

这是我从宏服务到微服务的系列文章的第一部分。 在这里，我将首先介绍为什么开发人员或经理会采取这样的行动的理由。 本系列后面的文章将提供代码示例和过程，以构建您自己的解决方案，并最终创建您的整个环境，在此环境中，您将用一系列微服务逐步替换宏服务。

为什么从宏观到微观的转变会令人生畏

开发大型系统时，我遇到的最常见的问题之一是，最初使用的技术已经过时了，添加新功能的学习过程很长。 这种情况需要您学习很多有关要使用的系统的知识。

重写系统是一个主意，但特别是对于大型系统，这会打开一罐自己的蠕虫。 您不仅可能会在现有错误的基础上引入新的错误，而且还不得不暂时维护两个系统。 让您的开发人员在新系统上工作（稍后）将在在线时获得回报，但在此之前，这是一笔费用。

大型宏服务也倾向于要求更长的学习时间。 模块会影响其他模块，添加功能通常需要您对要修改的系统有很好的了解。

例如，从理论上讲，数据导出功能可能很容易创建，而实际上只需要几天或一周的编程时间即可。 但是，对底层系统不熟悉的人可能最终会花费数周的时间，只是为了找到所有会受到添加影响的角落。 这导致系统依赖于熟悉它们的人，这使得外包成为现实。

通过立面服务弥合差距

我正在使用的特定宏服务系统的主要问题是其过时的技术。 它的某些部分源自具有10年历史的设计，并且对旧系统的依赖性很高。 在添加新功能或对其进行更改时，需要对其进行不断维护，从而使处理变得一团糟。

由于该系统具有许多旧的依赖项，因此还需要一些不再维护的库或多年来更改其功能的库。 这迫使我们保留旧版本或花费宝贵的时间来更新系统，以利用新的库，这通常意味着进行的工作无法提供可衡量的价值。

等到门面服务。

当您具有复杂的基础系统并且需要将其打开以供其他服务使用时，通常会使用外观服务，但是您不想打开整个端点。 因此，您改为创建一个代理接口，该接口仅提供您想要的功能。 例如，您可以创建REST服务以从SOAP系统读取数据。

我将系统转换为外观服务的第一个经验是当我们这样做时：我们将宏服务直接绑定到HTML前端，并且我们需要一种方法来打开它供移动应用程序使用。

在这种情况下，我们已经有一个向世界开放的接口，因此外观服务的想法是最初创建一个简单的代理，该代理仅中继请求，不提供任何其他功能。

创建这样的内容并让负载均衡器将其用作主要接口，而将实际API用作辅助接口，则可以轻松进行测试，直到代理服务稳定为止。 完成此操作后，用新代码替换旧功能以及向API添加以前不存在的新功能变得容易得多。

新功能，新技术并且以安全的方式

当我们的Facade代理API上线后，用新功能替换现有功能以及向系统添加新功能变得更加容易。 您要做的就是分析即将到来的请求。

例如，来自我们知道是IP /用户名/ etc等开发人员的来源的请求吗？ 将其路由到新服务。 如果不是，则使用旧的。 对于您的系统用户，添加是完全透明的，可能会增加响应的几毫秒，但是从开发人员的角度来看，这使您可以安全地测试和部署新服务。

例如，如果端点只是重写，则可以让10％的请求使用新的端点，而90％的请求使用旧的端点，并对速度，稳定性等进行分析。 如果出现问题，只需切换一下即可使用旧系统。

拥有这样的端点还可以使您执行许多以前不可能完成的新工作。

我正在使用的另一个系统的负载非常大。 有时，有很多用户在运行复杂的请求，这导致更高的负载和更长的响应时间。 该系统没有适当的自我复制方法。

因为根本不考虑底层系统的设计，所以运行它的多个实例或创建新功能以启动更多实例以同时运行将是一项艰巨的任务。 最终，对于某些事情并不会经常发生，这将需要大量的工时。 它发生时看起来很糟糕，但这不是一个真正的问题。

我们拥有技术。”

以此类推。 构建新架构的选择很明确：Docker容器。 容器不仅可以防止“在我的计算机上工作”这样明显的问题，而且可以使您随意随意地使用隔离的程序包，并且这些程序包具有设计上的模块化体系结构，这使得从旧系统到新系统的更改明显更容易，更便宜。

您可以在需要的时候轻松产生更多的端点，而不是让大型实例在空闲时间闲置大量资源，从而节省资金，在我们的情况下，还可以解决诸如响应时间变慢等表面问题。

除了Docker容器外，构建新系统时我最初使用的框架是Node.js。 我对此有很多经验，但是在检查了最先进的技术之后，Node.js似乎正在Swift失去作为简单Web API的基础，而新的王者是Go 。 甚至到Node.js主要开发人员跳船的地步。

如果您具有C类语言的背景知识，那么Go就会很容易学习。 它已经成熟并具有许多特质，真正使它成为中小型Web应用程序的语言。

借助Docker，Facade Services开辟了可能性

有了Docker，您就可以使用自己选择的工具来创建微服务，从而不再局限于一种语言和一种框架。 每个微服务可以使用最适合其任务的任何东西。

无需依赖已学习旧系统及其秘密的开发人员，您可以与一个小组合作来开发特定的功能，只需向他们提供旧API的文档或虚拟数据库/服务中的原始API等。签约团队不再需要成为应用程序方面的专家，而只需成为其正在构建的特定功能。 仅此一点就为您的应用程序的未来打开了新的可能性之门。

您的内部开发人员也不会在向过时的系统中添加功能，创建更多要维护的依赖方面进行过多的工作，而是会创建可以在制作和测试后立即部署的新功能，而不必测试整个系统反对变化。

尽管创建骨架功能来替代旧功能将有无利可图的工作，但创建原型微服务比开始安排设计新系统的会议的成本更具成本价值。 最后，以这种方式创建的微服务可能需要较少的开发人员作为维护和丰富您的服务的劳动力。

结论

我认为很明显，微服务可以满足当今的开发需求。 与Docker容器一起使用，与传统的宏服务相比，它们提供的依赖项更少，可扩展性更高。 他们还提供了许多解决方案，以维持少量，专注的开发人员，甚至可以相对轻松地外包未来的功能开发。

在本系列的下一篇文章中，我们将继续提供有关将外观服务作为Docker容器部署到AWS的教程。

翻译自: https://www.javacodegeeks.com/2017/02/simplifying-transition-macro-microservices.html

如何简化宏运算?