我们来研究下国内做的比较好一点的微服务框架，首先研究了下Pig。

1、 整个框架中采用了Nacos的服务注册和全局配置中心。

2、 使用的是Spring Cloud Gateway网关，自行在基础上实现了一些定制。

3、 前后端完全分离，前端使用了vue和Nodejs.

4、 加入了Redis的缓存机制。

5、 号称完全开源，其实是部分开源，开源代码中好些子项目没有，比如定时任务、分布式事务工具包、图形化模块(包含工作流引擎)等。这些都在付费的升级版本中。

我们来看一下他的程序的整体功能架构：

我们采用分类【classify】、对比【contrast】、扩展【extend】、归并【Merge】的方法来根据目前市场上已有成熟的产品作为参考来整理最全面和完整的功能功能架构，我把这种方放简称为CCEM，下面我将使用该方法来逐步推进微服务体系功能架构的功能设计。

首先我们从ping的功能模块图中看到，pig的整体功能模块划分如下：

对于整个模块划分，根据我们的理解不是特别认同，所以基本他的模块划分，我们先进行第一次分类和整理：

第二个Zheng，呵呵，这个命名好听一点，这个打开来项目更多，这个拆分得更细，代码我大致看了一下，不完整且无太大借鉴价值：

我们来看以下他的整体功能结构划分：

我们结合上面的功能分类再进行对比分析，识别出来不同的功能进行扩展，相同的功能进行归并，得到如下表：

最后我们来看一下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的方法分析和总结后，我们得到最全面的微服务架构如下：