转型微服务的始末

一纾罗
Jun 17, 2022
3 min read

问题

笔者在海外仓公司工作5年，负责公司所有软件系统开发。包括逆向物流系统，转运打单系统以及库内柜管理系统。因为一开始研发部门只有2个人，为了项目快速交付，减轻开发人员的技术栈压力，采用单体式应用程序(Monolithic application)。选取的是Django框架做web开发。随着系统功能的不断完善，开发人员的更替等，单体式应用程序遇到非常多的问题。

问题一:各层拓展受限严重,比如前台需要从Django Template切换到ReactJS,会造成原来的模板系统,登陆系统以及翻译功能不好使，切换成本高；后台DB请求想要从ORM切换到自己的数据库接口层同样非常困难。Monolithic application无形中限制技术的拓展。

问题二:代码安全性,整个系统将会对每个研发人员完全开放。每个人都能拥有整个代码副本，十分不安全。

问题三:整体逻辑复杂，技术多样，不容易进行修改和新人上手。甚至系统设计的时候也会容易陷入混乱，代码BUG频出。

问题四:多系统复用功能模块问题.我们开发了A,B,C三个系统，但是他们都开始使用添加a模块，一开始的做法是把模块内嵌到各个系统中，随着运行和功能的添加，每个系统的模块a都在进行自身的优化，造成了一个类似功能被重复开发并且系统之间可能由于开发人员的不同，进行了不同的修改。浪费大量资源。

解决思路

系统架构发展:

Monolithic appliation：整个系统集中在一个项目工程内。
分布式系统：开始按照模块将一个系统划分为若干个系统,例如前后端分离。
SOA框架：将整个业务多个系统进行切分和整合，引入消息和中间层处理，强调系统集成和模块化，完善业务模块之间的通信调度。
微服务：对SOA进一步优化，模块划分更加细微，轻量级通信（REST/HTTP），更加复杂的系统结构

如何从单体式系统转换为SOA/微服务:

对于一些正在运行的业务来说，原则上来说不存在关闭业务，再进行几个月开发重新上线一个测试都还不稳定的微服务版本系统，也就是说运行正常的单体式系统没必要拆。我们第一步是对有需要的系统进行前端升级，比如需要对API模块的数据实现前端可视化；第二步是开始建立一些系统的服务模块，比如把所有外部通信集中在一个模块;第三步,开始对数据库进行抽离,构建主数据库同步系统，备份数据库，建立索引以及统一数据层接口;第四步开始抽取一些公用接口，建立中间件。