微服务架构-从概念模型到知识体系化(7.7)

最近1到2年，在我博客上写了不少的微服务架构相关的文章，这篇文章刚好结合微服务架构相关的文章和实践，来进一步整理如何从一个新的知识点，在不断学习和实践中，将相关的内容知识体系化。

对于新领域的学习，我前面也专门写过如何快速切入新领域的文章，在此不再赘述。

在我接触微服务架构的时候，首先看下自己已有了SOA，云计算，私有云PaaS平台，敏捷开发，持续集成和CMMI过程改进等多方面知识点的积累。因此当接触到微服务架构的时候，自己首先思考的还是微服务架构和SOA有什么区别和关系，微服务网关和ESB有什么区别，微服务架构和原来的组件化架构有什么区别？

在学习微服务架构的文章过程中，不断的去思考这些关联和区别，其核心的目的仍然是真正找到微服务架构的核心，或者说你自己能够理解的概念模型。即 微服务架构本身是将传统单体应用打破为多个独立自治（可以在自己独立进程中运行）的微服务模块，同时这些模块间通过轻量的Http API接口进行交互 。这就是微服务架构的核心概念模型。

和SOA的区别，即SOA的概念内化到单体应用内部，单体应用拆分为微服务模块了。同时可以看到微服务架构并没去强调SOA里面的第二个层次，即服务能力的组合，组装和编排。和ESB的区别，微服务架构网关才是和ESB对应的东西，只是网关更加轻量，没有大量的遗留适配，协议转换等，同时接口基本推进主流的Http Rest模式。而同传统组件化架构的区别，则更加强调了组件完全独立自治，从数据库到应用层全部要拆分。

学习任何一个新概念或切入一个新领域，重点就是要抓住核心概念模型。你把核心抓住了，就达到了从道理上懂了的第一步，当然从道理上懂了，到你自己能够亲自去做，能够按这个思想去实践还差的远 。但是你抓住了这个概念模型，你后面所有的深入都将围绕这个核心展开。

大家可以看下我blog上关于微服务架构的文章，这些文章相对零散。

如果简单总结的话会涉及到如下关键词内容，传统企业IT架构转型，中台构建，微服务网关，SpingCLoud，DevOps和持续交付，容器化部署，服务注册发现，流量控制和熔断，微服务模块的拆分，微服务API接口的识别和定义，服务治理，微服务开发框架，微服务实施，HttpRest接口，微服务模块集成，开发过程，技术中台。

而所有上面的内容基本都围绕微服务架构相关点展开，那么这些零散的点到后面就需要进行整理和归纳，让零散的知识体系结构化。如何结构化？简单来说仍然还是这些知识朝上面聚合，而聚合后可能形成动态结构，也可能形成静态结构。

再来看微服务架构核心概念模型：即做两件事，一是拆分微服务模块，一是模块开发和集成，形成完整应用。那么再展开来看，从动态分析思路，微服务架构完整的生命周期就可以理解为：

规划咨询-》架构设计-》微服务模块开发-》上线运行-》微服务架构应用治理

对于规划咨询+架构设计：重点就是要定义清楚微服务模块，同时定义清楚模块间的Http API接口。对于后续各个阶段重点是开发微服务模块，并完成集成上线。而应用治理则重点是后续的管控和运维。

在这个大脉络梳理清楚后，你会看到微服务架构开发框架在微服务模块开发这个阶段，而这个开发框架即使从开业的SpringCLoud来说，这个框架就会包括（服务注册发现，流控，负载均衡，微服务网关，安全）等关键的技术组件，而这本身就是一个静态架构展开了。

把这个梳理清楚后，你会发现我们还谈到的微服务架构规范体系，DevOps和持续集成在哪个位置？而这些内容刚好就是横向底层重要的支撑过程。首先是规范体系，其次是DevOps持续交付过程和方法论。

对于架构设计，一个重要工作就是识别和定义微服务模块组件，同时定义组件间的http api接口。在谈整体架构框架的时候，参考SOA思想，一个重点就是分层，而这个分层重点就是形成技术中台+业务中台+上层应用的多层分层架构。上层的应用应该是基于技术中台加业务中台的能力进行组装，组合而构建出来的。

一个流程引擎的微服务模块，属于技术中台，而一个是产品中心的微服务模块则属于业务中台（业务中台包括了数据中心和业务规则处理中心）。

再回来看，还剩余的类似Docker容器技术和自动化部署，完全是属于我们整个DevOps支持过程里面的一个子过程和最佳实践了。即没有采用容器化部署并不影响整个架构体系是微服务架构。但是采用了容器化+DevOps是业界推荐的最佳实践而已，这种最佳实践可以进一步提升效率和自动化程度。

一个微服务架构更加不是否定了传统的软件生命周期，软件工程和软件项目管理，而是结合微服务架构的特点，更加强调了敏捷方法论和持续交付，持续集成的内容而已。这个时候就需要考虑我们的敏捷方法论，持续集成等最佳实践如何和微服务架构下的开发集成进一步结合。

经过上面思考，你会看到微服务架构知识体系，由前面说的最核心的 微服务架构生命周期，进一步扩展到规范体系和支撑工具集，软件项目管理和敏捷方法论三者的融合 。而这和传统的CMMI谈的项目管理+软件工程+支撑过程域也是完全对应的。

有了上面的思考，基本就可以看到微服务架构整体知识体系就梳理清楚了。

但是可以看到上面仍然还是从道理上面的进一步阐述，你只是道理上理解的更加细化了，接着要做的还是围绕这些知识点展开实践，你可以从采用最近的SpringCloud框架，开发Rest接口服务做起，然后再过渡到多个微服务模块间的持续集成，后期的微服务架构管控治理。

只有这样，你才能对微服务架构有完整的理解，而不是仅仅局限在会使用SpringCloud框架。