这是什么问题
好多第一眼看到这个问题的人难免一脸懵，微服务不就是把单体应用拆分成多个细粒度的服务吗？怎么还提出存量系统处理的问题？？？
这里说的存量系统处理问题是指那些部署了十几套，几十套业务系统的中大型传统企业，像银行，机场，券商，电信……这些机构在拥抱微服务架构技术的时候如何处理已有的大量存量系统？全部重新构建？花费巨额成本建成的IT资产就这么被废弃，岂不浪费？再者风险很大，大量处于运维期的系统推倒重来难免出现这样那样的问题。
想要追随技术发展的趋势，势必要实事求是，采取切实可行的方案。
存量系统如何纳入微服务架构
局部试点，逐步替换
对于已经决定拥抱微服务架构的机构来说，选择某个非关键系统作为试点，验证技术，以网关为桥梁，打通新老系统的交互渠道，逐渐从以原有系统为主过渡到以微服务架构为主。
采用边车模式保留存量系统
对大部分机构而言大量的原有系统运行良好，负载合适，只是部分系统无法满足当前的业务需求需要新建，在新建的过程跃跃欲试，想要尝试微服务架构，微服务架构的统一注册，配置，统一管理监控，确实是架构的升级。但采用微服务架构的应用与其他存量系统如何交互？存量系统如何纳入微服务架构？我以为边车模式是一种可行的方案。
特别是当存量系统采用了大量非RestAPI(http+json)的通讯方式，让采用微服务技术的新建系统都去适配这些原有的通讯方式无疑工作量巨大，整体看又是大量的重复功能，对新建系统不够友好。无论是第一种方案里的网关还是第二种模式里的边车，本质上都是一种代理，解决这种异构场景的系统交互问题。
使用边车作为存量系统的代理，完成通讯，接口的转换及服务注册调用，将存量系统融入到微服务架构，可以最小限度的降低改造工作量及成本，让原有的IT资产继续发挥效用，同时可以利用新的技术成果。
Commander 是一个支持多种通讯方式及报文格式的边车系统（Sidecar）或代理(Proxy)，由IDE和运行时两部分构成。IDE是一个基于Eclipse的低代码开发平台。无需编写大量的通讯代码，通过简单配置相应的通讯参数，拖拽相应的处理流程即可完成开发。。
欢迎对Commander感兴趣的朋友访问Commander: Commander 是一个服务编排框架库。由IDE和运行时两部分构成。IDE提供所见即所得的组合服务配置，接口配置，及处理流程，是一个低代码开发平台。
