微服务迁移：经验教训
“微服务”是最近一段时间在科技领域发生的一个热门词汇。 我们最终决定迁移到微服务架构，并希望分享我们为什么这样做，我们是如何做到的，以及我们沿途学到的东西。
与大多数Web应用程序一样，Andela的系统开始是一个“单片整体”软件架构，包含几个Web应用程序，每个都有自己的数据库并负责业务功能。 例如，我们构建了不同的网络应用程序来管理申请人的招聘，选择，学习成绩评估和技能的掌握，这对开发世界级开发人员都至关重要。
随着我们的应用程序套件的增长，我们遇到三个主要挑战：
1.在应用程序中有很多重复的业务逻辑。
2.跨应用程序连接数据有问题。
3.不断增长单片代码库导致产品交付速度较慢。
以前我们构建独立的单片应用程序是为满足特定的业务需求，而不是为了实现数据连接应用的生态系统，而后者越来越符合我们的业务运营方式。
很明显，为了扩展，我们需要重新思考我们的软件架构。在研究不同类型的架构，我们碰到这个博客帖子nginx ，它推动我们向微服务努力方向。在确定了为什么微服务将有助于解决我们的挑战以后，我们决定迁移并开始旅程。
执行
我们首先学习尽可能多的微服务：它们带来什么，他们提出了什么挑战，以及它们可能对我们的团队结构和敏捷过程产生的影响。 我们任命Ikem Okonkwo领导这个研究，并领导一个初始有五个开发人员的核心团队，于是就开始了。他们的研究结果及提出的设计考虑都发表了博客文章 。一旦我们对调查结果感到满意，我们开始合并在一起执行计划。
核心团队起初是建立我们新的基础设施，创造了不同的语言微服务模板，建立我们的托管服务（我们离开Heroku搬到到谷歌云），设置Kafka卡夫卡 （分布式流媒体平台），设置如何管理我们的服务器和集群（ Kubernetes ），并建立持续集成（ ConcourseCI ）。
一旦我们的最低基础设施需求到位，所有的功能团队开始将我们的产品迁移到微服务。结果，在六个月的时间里，我们将五个关键的单片系统解耦到35个微服务，前端应用程序通过API网关与后端系统交互。 这项工作涉及15名工程师努力工作，以改善我们的平台。
得到教训
执行迁移并不是在公园里散步。我们在路上犯了一些错误，虽然幸运的是我们能够吸取学习了教训。 这里有一些在开始迁移之前我们考虑过的事情：
1.学习曲线 ：从建立大应用单元过渡到相对于小的，独立发布的单元。这一点很重要，因为构建分布式系统会影响团队结构，以及它们如何沟通以完成工作。
2.UUID：使用单片系统通过自动递增的工作得够好，但在分布式架构中，最终会碰到冲突。UUID允许我们跟踪不同的业务逻辑并跨生态系统连接它们。
3.入门套件 ：样板代码必须包含开发和部署新的微服务的所有的一切。入门工具包特别有助于加快新开发人员的开发和入职。
4.自动化 ：一个连续的递交流程和自动化的环境设置，能够帮助我们的工程师能高度自主地编写，测试和递交代码。
5.快速完成 ：当我们迁移平台时，相对现有代码库功能开发的进度好像一场比赛。迁移需要比其代码库本身开放更快地推进。 必须有一支强大的工程师团队，能够快速，快速地完成迁移。
尽管我们面临各种挑战，移民还是成功得，我们相信我们做出了正确的决定。我们将继续利用我们的学习，改进我们的平台和软件开发过程。我们现在比以往任何时候都更有信心，我们有能力快速迭代产品，为业务提供一致的价值。