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

今天谈下企业如果实施微服务架构转型和改造,可能涉及到的内容和范围。

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

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

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

其次,微服务开发框架的选择,开发技术标准和规范体系的建设,这个也是一个关键的内容,即在采用微服务架构后,需要制定一系列的技术架构标准,开发标准规范体系,数据库规范体系等。包括选择什么开源的微服务开发框架和组件,每个微服务模块的接口接入和发布标准,接口使用标准,模块内的代码编写标准规范。也包括软件过程支撑中的关键规范,包括配置管理,编译,构建,测试,部署等,这些都需要一套标准规范体系支撑。

也就是说这些都制定好了,一个开发商可能分包到一个大系统的一个微服务模块,那么基于这些规范体系,基于微服务模块的需求说明和接口定义标准,就可以开始微服务模块的开发和交付,同时这些微服务模块之间本身通过前期架构设计定义好的微服务API接口服务能够完成相应的集成和交互。

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

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

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

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

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

我来评几句
登录后评论

已发表评论数()

相关站点

热门文章