微服务架构改造案例

最后一个部分，结合我们自己的财务共享平台项目进行了微服务架构改造案例分析。

对于改造前的应用，实际上存在四个方面的问题。

其一是关于高可用性方面的，即传统的单体应用我们在进行数据库水平扩展的时候已经很难扩展，已经出现了大并发，大数据 量下数据库的性能问题。

其二是多团队异地协同上，传统的 IT 架构很难进行更好的多团队分工，同时在异地协同过程中对于开发，测试，前方实施经常出现大量的无效沟通情况。

其三是敏捷性已经不能满足客户的需求，比如我们一个小版本规划最少 2 到 3 周，而很多时候在客户往往我们能够在一周就实施 一个变更版本上线。

其四是开发和运维之间的沟通协同困难，同时由于原来是一个大单体应用，版本升级和变更同样困难，一个是部署包好几百 M很难管理，一个是往往修改A 模块功能导致 B 模块出现异常等。

也正是由于这些原因我们启动了项目的微服务架构改造工作。

在整个改造过程中，重点仍然是如何划分微服务，而核心思路仍然是流程分析入手。即：基于业财一体化最佳实践，重新梳理 端到端业务流程和协同，找到关键阶段划分。对于关键阶段进一步细化，分析详细的业务操作和协同流程( 二到三级流程）。

我们首先进行粗颗粒度的模块拆分和集成分析，在分析完成后储备可以明确的识别出类似报账，资金，发票，电子凭证，影像，预算，ERP 集成等关键微服务模块。

在微服务模块识别完成后，我们还需要针对单个微服务进一步进行业务交互和协同分析，以梳理和识别API接口服务能力。

在整个微服务架构改造和转型中，我们还需要进行技术平台的统一。采用 SpringCloud 框架体系，启用注册中心，负载均衡，限流熔断，网关能力。同时前后端完全分离开发，前端基于VUE 框架进一步封装和定制。

我们采用禅道项目管理工具统一敏捷研发管理，需求拆分到用户故事点实现端到端管理，形成产品-微服务两级的产品架构和版本管理体系，实现和持续集成和版本发布过程集成。

同时我们采用 DevOps 支撑平台来实现整个微服务架构设计和开发过程中的持续集成和交付能力。对于 DevOps 平台的核心架构和功能，可以参考我前面发布过的文章详细了解。

在整个DevOps实施过程中，我们通过 DevOps 流水线对大量的开源工具进行了整合。其中包括了 Git 库， Sonar 静态代码检查，Jekins 持续集成， Kurbernetes 和 Docker 容器，自动化测试工具， ELK 日志采集和分析，监控工具等。

实现研发过程和 DevOps 过程的集成。一个 DevOps 支撑平台离不开和容器化 PaaS 平台的集成，即最终的编译构建完成的内容形成镜像并放到镜像仓库，后续部署，环境迁移，资源扩展基于镜像仓库进行快速的拷贝和复制。

对于Docker 容器一般会和 K8S结合来实现资源的动态调度，集群管理能力。环境迁移是基于镜像进行环境拷贝和迁移，而不再需要重新构建和打包，这也是我们原来在谈持续集成技术的时候一直强调的一点。只有这样才能够保证测试通过的包就是最终部署到生产环境的包。

对于DevOps实施效果可以总结为，版本构建频度： 2 天一次 -> 半天一次或实时触发；版本构建时间：缩短到 1 分钟内完成；应

用交付部署：实现环境自动化迁移和云部署；测试执行效果：接口测试全部自动化。