微服务架构趋势下如何处理存量系统

这是什么问题

好多第一眼看到这个问题的人难免一脸懵，微服务不就是把单体应用拆分成多个细粒度的服务吗？怎么还提出存量系统处理的问题？？？

这里说的存量系统处理问题是指那些部署了十几套，几十套业务系统的中大型传统企业，像银行，机场，券商，电信……这些机构在拥抱微服务架构技术的时候如何处理已有的大量存量系统？全部重新构建？花费巨额成本建成的 IT 资产就这么被废弃，岂不浪费？再者风险很大，大量处于运维期的系统推倒重来难免出现这样那样的问题。

想要利用技术发展的优秀成果，势必要实事求是，采取切实可行的方案。

存量系统如何纳入微服务架构

一，      局部试点，逐步替换

对于已经决定拥抱微服务架构的机构来说，选择某个非关键系统作为试点，验证技术，以内部网关为桥梁，逐渐从以原有系统为主过渡到以微服务架构为主。

二，      边车模式

对大部分机构而言大量的原有系统运行良好，负载合适，只是部分系统无法满足当前的业务需求需要新建，在新建的过程跃跃欲试，想要尝试微服务架构，微服务架构的统一注册，配置，统一管理监控，确实是架构的升级。但其他存量系统怎么办？我以为边车模式是一种可行的方案。

service mesh

使用边车作为存量系统的代理，完成通讯，接口的转换及服务注册调用，将存量系统融入到微服务架构，可以最小限度的降低改造工作量及成本，让原有的 IT 资产继续发挥效用，同时可以利用新的技术成果。

边车代理

Commander 是一个支持 Orchestration 和 Choreography 两种模式的服务编排框架库，可作为存量业务系统的边车，由 IDE 和运行时两部分构成。IDE 是一个基于 Eclipse 的低代码开发平台。

欢迎对 Commander 感兴趣的朋友访问https://gitee.com/meta_soft/commander

联系方式 meta_soft@163.com