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

　　今天谈下企业如果实施微服务架构转型和改造，可能涉及到的内容和范围。
　　一个企业实施微服务架构，不是简单地使用一个开源的微服务架构框架，搭建一个微服务平台就完事，更加重要的往往是前期的微服务模块的拆分和定义，后期的微服务架构整体的治理和运维。
　　首先，是微服务模块的拆分，原来的一个单体应用究竟应该拆分为几个微服务模块，每个微服务模块多大体量才合适？同时微服务模块里面哪些是技术模块，哪些是数据模块，哪些是业务规则处理模块，哪些是前端应用模块？如何参考互联网中台构建思路来建设中台能力中心并进行能力开放，一个微服务模块究竟应该开放哪些微服务接口API服务能力？这些都必须要思考清楚。而这些内容本身更多的是业务层面，需要基于业务流程和业务场景的分析，数据架构的分析来考虑微服务模块的拆分，以确保各个模块间松耦合的关系。
　　传统的一个单体应用，原来我们本身也会拆分为多个业务模块，而这个可以作为拆分为微服务模块的一个参考，但是不是全部。对于模块实际的拆分一定还需要考虑模块间的接口耦合度，后期微服务模块的管理和运维方便性等多个方面进行思考。
　　其次，微服务开发框架的选择，开发技术标准和规范体系的建设，这个也是一个关键的内容，即在采用微服务架构后，需要制定一系列的技术架构标准，开发标准规范体系，数据库规范体系等。包括选择什么开源的微服务开发框架和组件，每个微服务模块的接口接入和发布标准，接口使用标准，模块内的代码编写标准规范。也包括软件过程支撑中的关键规范，包括配置管理，编译，构建，测试，部署等，这些都需要一套标准规范体系支撑。
　　也就是说这些都制定好了，一个开发商可能分包到一个大系统的一个微服务模块，那么基于这些规范体系，基于微服务模块的需求说明和接口定义标准，就可以开始微服务模块的开发和交付，同时这些微服务模块之间本身通过前期架构设计定义好的微服务API接口服务能够完成相应的集成和交互。
　　再次，微服务架构实施过程中的过程支撑能力。在实施微服务架构的时候，需要一系列的开源工具和方法进行组合，包括我们经常谈到的微服务架构和Docker容器技术的集成，和DevOps持续交付过程，敏捷开发方法论的集成等。这些都需要配置管理，变更管理，项目管理，构建打包，部署，单元测试等一系列的开源工具配合，以确保上面整个过程能够大部分实现自动化和流水线作业化，只有这样整个过程才可能高效和可视。
　　而我们前期研发的DevOps支撑平台，主要就是为了解决上面这些问题，真正将整个基于微服务架构的开发，构建，集成和部署过程全部串联起来。把微服务架构Docker容器技术持续集成方法串联起来，形成一整套的可复制和标准化的敏捷开发过程。
　　注意在进行微服务化拆分后，往往是本身的问题驱动你必须上CICD或DevOps过程实践，来讲大量重复集成，交付工作自动化。
　　最后，就是微服务管控治理和运维能力。在一个微服务架构的实施过程中，一个传统的单体应用会拆分为多个微服务模块，同时原来的系统间交互接口会变为微服务模块间的交互接口。因此对于需要管理的模块单元数，接口服务数都会成倍地增加，再加上容器化的自动部署和托管，实际上对整个IT基础设施和应用架构，包括集成关系的管理难度都将更加困难。因此在微服务架构实施过程中，不仅仅是建设完成就了事，更加重要的是后期的监控和运维，服务治理能力。
　　因此企业在建设和实施微服务架构的时候，必须要考虑后期的微服务架构下的模块监控和运维，微服务API接口的状态监控，类似APM的应用性能监控，服务链监控等。在这个过程中除了使用SpingCLoud框架外，你可能还会引入其他第三方的服务监控治理开源工具，比如Apollo的服务配置中心，Skywalking限流熔断，Nacos的服务注册和配置中心，Sentinel限流熔断等。包括在后期整个微服务治理管控朝ServiceMesh化的演进和过渡。
　　企业对于微服务架构的建设和实施，实际上和我12年开始写的企业私有云PaaS相关文章很类似。对于完整的微服务架构的搭建，如果从横向分层的角度来看，分为技术后台，业务中台和应用前台。而对于技术中台主要是提供类似消息，缓存，日志，文件，通知，流程引擎，4A等共性技术服务能力，这些技术服务模块本身也是微服务模块，属于厚PaaS平台层的内容。而对于业务中台本身又包括了关键的类似MDM主数据能力平台，这些也都需要统一规划建设。
　　微服务架构本身是和Docker容器化结合紧密，当时你没有采用容器化PaaS也可以实施微服务架构，只是采用容器化架构后，整个基础设施架构更加容易自动化的弹性扩展和调度，整个架构平台的弹性扩展能力都大大增强。同时也会使整个微服务架构持续集成过程更加快速和高效。