微服务迁移:经验教训

16-11-24 banq
“微服务”是最近一段时间在科技领域发生的一个热门词汇。 我们最终决定迁移到微服务架构,并希望分享我们为什么这样做,我们是如何做到的,以及我们沿途学到的东西。

与大多数Web应用程序一样,Andela的系统开始是一个“单片整体”软件架构,包含几个Web应用程序,每个都有自己的数据库并负责业务功能。 例如,我们构建了不同的网络应用程序来管理申请人的招聘,选择,学习成绩评估和技能的掌握,这对开发世界级开发人员都至关重要。

随着我们的应用程序套件的增长,我们遇到三个主要挑战:

1.在应用程序中有很多重复的业务逻辑。

2.跨应用程序连接数据有问题。

3.不断增长单片代码库导致产品交付速度较慢。

以前我们构建独立的单片应用程序是为满足特定的业务需求,而不是为了实现数据连接应用的生态系统,而后者越来越符合我们的业务运营方式。

很明显,为了扩展,我们需要重新思考我们的软件架构。在研究不同类型的架构,我们碰到这个博客帖子nginx ,它推动我们向微服务努力方向。在确定了为什么微服务将有助于解决我们的挑战以后,我们决定迁移并开始旅程。

执行

我们首先学习尽可能多的微服务:它们带来什么,他们提出了什么挑战,以及它们可能对我们的团队结构和敏捷过程产生的影响。 我们任命Ikem Okonkwo领导这个研究,并领导一个初始有五个开发人员的核心团队,于是就开始了。他们的研究结果及提出的设计考虑都发表了博客文章 。一旦我们对调查结果感到满意,我们开始合并在一起执行计划。

核心团队起初是建立我们新的基础设施,创造了不同的语言微服务模板,建立我们的托管服务(我们离开Heroku搬到到谷歌云),设置Kafka卡夫卡 (分布式流媒体平台),设置如何管理我们的服务器和集群( Kubernetes ),并建立持续集成( ConcourseCI )。

一旦我们的最低基础设施需求到位,所有的功能团队开始将我们的产品迁移到微服务。结果,在六个月的时间里,我们将五个关键的单片系统解耦到35个微服务,前端应用程序通过API网关与后端系统交互。 这项工作涉及15名工程师努力工作,以改善我们的平台。

得到教训

执行迁移并不是在公园里散步。我们在路上犯了一些错误,虽然幸运的是我们能够吸取学习了教训。 这里有一些在开始迁移之前我们考虑过的事情:

1.学习曲线 :从建立大应用单元过渡到相对于小的,独立发布的单元。这一点很重要,因为构建分布式系统会影响团队结构,以及它们如何沟通以完成工作。

2.UUID:使用单片系统通过自动递增的工作得够好,但在分布式架构中,最终会碰到冲突。UUID允许我们跟踪不同的业务逻辑并跨生态系统连接它们。

3.入门套件 :样板代码必须包含开发和部署新的微服务的所有的一切。入门工具包特别有助于加快新开发人员的开发和入职。

4.自动化 :一个连续的递交流程和自动化的环境设置,能够帮助我们的工程师能高度自主地编写,测试和递交代码。

5.快速完成 :当我们迁移平台时,相对现有代码库功能开发的进度好像一场比赛。迁移需要比其代码库本身开放更快地推进。 必须有一支强大的工程师团队,能够快速,快速地完成迁移。

尽管我们面临各种挑战,移民还是成功得,我们相信我们做出了正确的决定。我们将继续利用我们的学习,改进我们的平台和软件开发过程。我们现在比以往任何时候都更有信心,我们有能力快速迭代产品,为业务提供一致的价值。

Microservices Migration: Lessons Learned – Technol

    

1
猜你喜欢