简化从宏服务到微服务的过渡

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

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

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

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

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

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

与立面服务之间的桥梁

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