国内流行的微服务框架对比和CCEM功能框架分析
2020-05-22 13:49阅读：
我们来研究下国内做的比较好一点的微服务框架，首先研究了下Pig。
1、
整个框架中采用了Nacos的服务注册和全局配置中心。
2、 使用的是Spring Cloud
Gateway网关，自行在基础上实现了一些定制。
3、
前后端完全分离，前端使用了vue和Nodejs.
4、
加入了Redis的缓存机制。
5、
号称完全开源，其实是部分开源，开源代码中好些子项目没有，比如定时任务、分布式事务工具包、图形化模块(包含工作流引擎)等。这些都在付费的升级版本中。
我们来看一下他的程序的整体功能架构：
我们采用分类【classify】、对比【contrast】、扩展【extend】、归并【Merge】的方法来根据目前市场上已有成熟的产品作为参考来整理最全面和完整的功能功能架构，我把这种方放简称为CCEM，下面我将使用该方法来逐步推进微服务体系功能架构的功能设计。
首先我们从ping的功能模块图中看到，pig的整体功能模块划分如下：
前端工程(类似于微服务管理门户)
|
认证和授权服务
|
微服务的公共模块(公共工具、公共数据、动态数据源、定时任务、动态路由、日志、文件、安全工具、全局ID生成器、Swagger集成、分布式事务)
|
全局注册和配置中心(阿里巴巴的Nacos)
|
微服务网关
|
Upms(用户权限管理)
|
图形化模块(SpringBoot
Admin监控、分布式调度、图形化代码生成器、分布式事务解决方案、工作流模块、微信管理模块、微信支付宝收单模块、SSO客户接入示例)
|
对于整个模块划分，根据我们的理解不是特别认同，所以基本他的模块划分，我们先进行第一次分类和整理：
微服务技术组件(偏技术和企业内部管理)
|
微服务管理门户
|
Upms(包含管理用户的认证和授权服务)
|
微服务公共技术模块(公共工具、动态数据源、公共数据、定时任务、动态路由、日志、文件、安全工具、全局ID生成器、Swagger集成、分布式事务)
|
全局注册和配置中心
|
微服务网关
|
微服务监控和分析
|
微服务分布式事务及调度管理
|
微服务框架代码生成器
|
微服务工作流引擎
|
微服务业务组件(偏对外业务和运营)
|
微信管理模块
|
支付模块(支持微信、支付包)
|
微服务组件开发示例
|
SSO接入示例
组件开发示例
|
第二个Zheng，呵呵，这个命名好听一点，这个打开来项目更多，这个拆分得更细，代码我大致看了一下，不完整且无太大借鉴价值：
我们来看以下他的整体功能结构划分：
我们结合上面的功能分类再进行对比分析，识别出来不同的功能进行扩展，相同的功能进行归并，得到如下表：
微服务技术组件(偏技术和企业内部管理)
|
微服务管理门户
|
Upms(包含管理用户的认证和授权服务)
|
微服务公共技术模块(公共工具、动态数据源、公共数据、定时任务、动态路由、日志、文件(OSS对象存储)、安全工具、全局ID生成器、Swagger集成、分布式事务)
|
全局注册和配置中心(Nacos/Consul)
|
微服务网关(ESB总线)
|
微服务监控和分析
(SpringBootAdmin,微服务监控)
(Zipkin/skywalking，APM/服务链监控)
(prometheus/grafana,日志监控/展示/告警)
|
微服务分布式事务及调度管理
|
微服务框架代码生成器
|
微服务工作流引擎
|
微服务业务组件(偏对外业务和运营)
|
Ucenter（用户中心）
|
微信管理模块
|
支付模块(支持微信、支付包)
|
内容管理模块(CMS),管理前台新闻、公告等等内容
|
消息实时推送模块
|
电子商务模块
|
微服务组件开发示例
|
SSO接入示例
组件开发示例
|
最后我们来看一下SpringBlade，首先来看一下SpringBlade的整体架构图设计，整个架构图可以说是非常清晰的描述了整个微服务的技术体系。
我们先来看一下这个项目的具体介绍：
Ø
采用前后端分离的模式，前端开源两个框架：[Sword] (基于
React、Ant Design)、[Saber]
(基于 Vue、Element-UI)
Ø
后端采用SpringCloud全家桶，并同时对其基础组件做了高度的封装
Ø
集成Sentinel从流量控制、熔断降级、系统负载等多个维度保护服务的稳定性。
Ø
注册中心、配置中心选型Nacos，为工程瘦身的同时加强各模块之间的联动。
Ø
使用Traefik进行反向代理，监听后台变化自动化应用新的配置文件。
Ø
极简封装了多租户底层，用更少的代码换来拓展性更强的SaaS多租户系统。
Ø
借鉴OAuth2，实现了多终端认证系统，可控制子系统的token权限互相隔离。
Ø
借鉴Security，封装了Secure模块，采用JWT做Token认证。
Ø 支持k8s
+ jenkins的部署架构
从整个技术体系上，目前我们整理的功能架构缺失了Sentinel，不过Sentinel服务限流、熔断、降级等功能可以在网关或者ESB上对照实现，这个就不再单独加进我们的功能架构中。资源管理就是类似我们的OSS文件资源对象存储。对于接口文档管理和调试我们合并放到微服务框架代码生成器里面，归并叫另一个名字微服务开发管理组件。这个框架的整体功能还是比较简单，对于业务类的组件实现拆分得更加细，除了少量的代码重新做过封装之外，基本上都是开源的，对于初学者来说，是我们学习微服务架构的一个很好的开始。
还有一个Guns框架，Guns的核心是roses-kernel项目，
Roses框架基于
Spring
Boot 2和
Spring Cloud
Finchley.RELEASE，整合
Eureka + Hystrix + Ribbon + Feign +
Zuul，因为这个项目更简单还不太完善，我们就不再这里详细的进行对比分析了。
最后总结一下微服务组件的拆分，业务组件的划分基本可以参照这几个框架，紧耦合的业务放在一起，对于功能和API拆开，功能内部如果不是特别原因(比如需要单独的组织管理、单独实现监控、扩展需求强烈，对外共享可能性高)不建议再拆分成多个细粒度的微服务组件，而功能和API应该放在一个项目组中，不建议像SpringBlade中功能模块和API拆分成两个项目组进行组织。
根据以上CCEM的方法分析和总结后，我们得到最全面的微服务架构如下：
微服务技术组件(偏技术和企业内部管理)
|
微服务管理门户
|
Upms(包含管理用户的认证和授权服务)
|
微服务公共技术模块(公共工具、动态数据源、公共数据、定时任务、动态路由、日志、文件(OSS对象存储)、安全工具、全局ID生成器、Swagger集成、分布式事务)
|
全局注册和配置中心(Nacos/Consul)
|
微服务网关(ESB总线) （spring
cloud网关/kong/sentinel/hystrix）
|
微服务监控和分析
(SpringBootAdmin |
