平台云化改造

平台云化改造(代码地址：https://github.com/blueskylong/aolie_parent）

当前的应用基本上都会基于云服务来进行构造，这里就不赘述云服务构架的优点了，直接进入主题

整体思路

原来的平台工程是基于微服务架构的，其实只能说应用了其自带tomcat的功能，最终构建出来的，还是一个大的单体应用，只是可以通过不同的组合，来组装平台的功能。云服务要打破原来的模块相互依赖方式，各个模块独立部署，对外提供服务。模块的划分基本上就按照原来的划分 进行，在外层增加网关层，并把认证和权限提前到网关层。
我将每个模块拆分成二块，一个为服务模块，提供业务服务，另一个为API模块，将外界需要的VO和服务接口放在其中。
如果使用的网飞的调用方式，则在API的模块中，就将服务注册完整，这样在其它模块调用时，即可直接引用。

技术选型

在技术上，整体采用SpringCloud Alibaba 的解决方案，主要考虑到这套架构也已十分成熟，且还在不断的发展中，而网飞的已不再更新。
由于是全新的系统，也不存在不同语言开发的问题，基本是在同一个内网中部署，所以主要采用RPC的调用方式提高效率。当然，由于SpringCloud的标准化，不排斥采用网飞的组件，可以根据业务的具体需求决定采用的技术。
具体使用的框架为：

• nacos ：用作注册中心，服务发现和配置中心。
• dubbo :RPC服务调用，各微服务间的服务调用，负载均衡，容灾等。
• Spring Gateway :网关,配合Spring Security
• seata :用于分布式事务，需要配合使用MQ组件。
• RocketMQ :配合seata,另外用于系统日志的收集。
• Redis :用于分布式Session的实现，数据的缓存。
• ShardingSphere : 可选项，用于动静分离，分库分表。
• sentinel :可选项 用于熔断、降级、限流，流量监控等。

模块划分

基本是依据原来的模块划分，除了核心模块，核心模块分解成核心模块和应用管理模块。每一个原始模块都拆分成原模块与API模块，原模块提供服务，API模块则提供接口和VO。
主要的功能模块有：

• aolie-core :核心服务，用于维护业务模型，提供业务模型相关服务
• aolie-core-api ：核心服务接口及业务类，以及本地服务模型相关的接口
• aolie-application ：应用框架服务，提供菜单、按钮、权限、用户等维护和查询
• aolie-application-api ：应用框架服务接口，对外提供登录服务
• aolie-common ：通用模块，提供工具类。不提供服务。
• aolie-gateway ：网关模块，提供网关功能，通用数据服务路由，根据模型对应的服务名（application_code)进行路由，只引用aolie-application的服务。
• aolie-gateway-api :网关服务，暂时没有对外的服务
• aolie-monitor ：业务模型监控服务，负责收集和展示业务模块的数据流状态
• aolie-query ：查询功能服务。用于查询表的设计及查询服务
• aolie-flow ：flowable流程管理服务，用于设计和流程控制
• aolie-flow-api ：对外提供流程服务接口

遇到的困难

• 循环依赖问题
  每个服务基本上都会依赖核心模块提供的服务，而核心部分应该保持相对的独立，除需要引用共用模块外，不应该再引用其它模块服务。
  然而核心部分对应用框架服务有依赖的部分，解决方法就是将可以细化拆分的服务再细分，实在不可以拆分的，就在核心组件中用另外一种方式实现一套，以供核心内部使用。
• 插件设计模式的困境
  原来的单体应用平台，很容易实现插件化的结构，只需要设计接口，提供实现即可。然而在分布式结构下，想实现这样的功能是有很大困难的，1.技术实现，因为不在一个容器中，并不能通过简单的注入来实现插件的插入。
  2.效率问题，如数据查询的过滤器插件，如果每次调用都通过远程的方式，性能上是个很大的问。3，插件需要作用于所有的微服务上，这样会使得调用链十分复杂。
  这个问题暂时没有好的解决办法，只是将必须的功能，集中放置到aolie-core-api模块中，以分发到各个模块中。
• 双重服务问题
  双重服务是指，一个本地提供的服务接口本模块和其它模块都需要使用，本地使用通过@Service注入即可使用，而其它模块则需要使用远程服务注入的方式才可以使用,然后二种引用方式，不能同时存在，这里采用提供二套服务的方式予以解决。
  即将原始服务派生出一个子类，并暴露出需要注入不同形式服务的属性，然后在二个服务类上加上服务注册的条件，即可实现在不同的环境下，注册不同的服务。如DmDataService服务

最终形态

如图：服务只与接口模块有引用关系。启动顺序要求，aolie-core -> aolie-application -> 其它