企业实施微服务架构的范围

Posted 2021-04-14 远见先行

       一个企业实施微服务架构，不是简单的使用一个开源的微服务架构框架，搭建一个微服务平台就完事，更加重要的往往是前期的微服务模块的拆分和定义，后期的微服务架构整体的治理和运维。

       首先，是微服务模块的拆分，原来的一个单体应用究竟应该拆分为几个微服务模块，每个微服务模块多大体量才合适？同时微服务模块里面哪些是技术模块，哪些是数据模块，哪些是业务规则处理模块，哪些是前端应用模块？如何参考互联网中台构建思路来建设中台能力中心并进行能力开放，一个微服务模块究竟应该开放哪些微服务接口API服务能力？这些都必须要思考清楚。而这些内容本身更多的是业务层面，需要基于业务流程和业务场景的分析，数据架构的分析来考虑微服务模块的拆分，以确保各个模块间松耦合的关系。

传统的一个单体应用，原来我们本身也会拆分为多个业务模块，而这个可以作为拆分为微服务模块的一个参考，但是不是全部。对于模块实际的拆分一定还需要考虑模块间的接口耦合度，后期微服务模块的管理和运维方便性等多个方面进行思考。

       其次，微服务开发框架的选择，开发技术标准和规范体系的建设，这个也是一个关键的内容，即在采用微服务架构后，需要制定一系列的技术架构标准，开发标准规范体系，数据库规范体系等。包括选择什么开源的微服务开发框架和组件，每个微服务模块的接口接入和发布标准，接口使用标准，模块内的代码编写标准规范。也包括软件过程支撑中的关键规范，包括配置管理，编译，构建，测试，部署等，这些都需要一套标准规范体系支撑。也就是说这些都制定好了，一个开发商可能分包到一个大系统的一个微服务模块，那么基于这些规范体系，基于微服务模块的需求说明和接口定义标准，就可以开始微服务模块的开发和交付，同时这些微服务模块之间本身通过前期架构设计定义好的微服务API接口服务能够完成相应的集成和交互。

       再次，在实施微服务架构的时候，需要一系列的开源工具和方法进行组合，包括我们经常谈到的微服务架构和Docker容器技术的集成，和DevOps持续交付过程，敏捷开发方法论的集成等。这些都需要配置管理，变更管理，项目管理，构建打包，部署，单元测试等一系列的开源工具配合，以确保上面整个过程能够大部分实现自动化和流水线作业化，只有这样整个过程才可能高效和可视。

       而我们前期研发的DevOps支撑平台，主要就是为了解决上面这些问题，真正将整个基于微服务架构的开发，构建，集成和部署过程全部串联起来。把微服务架构+Docker容器技术+持续集成方法串联起来，形成一整套的可复制和标准化的敏捷开发过程。

       在一个微服务架构的实施过程中，一个传统的单体应用会拆分为多个微服务模块，同时原来的系统间交互接口会变为微服务模块间的交互接口。因此对于需要管理的模块单元数，接口服务数都会成倍的增加，再加上容器化的自动部署和托管，实际上对整个IT基础设施和应用架构，包括集成关系的管理难度都将更加困难。因此在微服务架构实施过程中，不仅仅是建设完成就了事，更加重要的是后期的监控和运维。因此企业在建设和实施微服务架构的时候，必须要考虑后期的微服务架构下的模块监控和运维，微服务API接口的状态监控，类似APM的应用性能监控，服务链监控等。

       再次企业对于微服务架构的建设和实施，实际上和我12年开始写的企业私有云PaaS相关文章很类似。对于完整的微服务架构的搭建，如果从横向分层的角度来看，分为技术后台，业务中台和应用前台。而对于技术中台主要是提供类似消息，缓存，日志，文件，通知，流程引擎，4A等共性技术服务能力，这些技术服务模块本身也是微服务模块，属于厚PaaS平台层的内容。而对于业务中台本身又包括了关键的类似MDM主数据能力平台，这些也都需要统一规划建设。

       微服务架构本身是和Docker容器化结合紧密，当时你没有采用容器化PaaS也可以实施微服务架构，只是采用容器化架构后，整个基础设施架构更加容易自动化的弹性扩展和调度，整个架构平台的弹性扩展能力都大大增强。同时也会使整个微服务架构持续集成过程更加快速和高效。