我的项目改造思路

       项目改造有时候第一印象就是微服务，拥抱SpringCloud这套生态，项目改造的目的是什么，

 要解决当下项目运行中的那类问题，从微服务出发固然是好，但项目人员少，缺少运维人员情况

 微服务好呢还是单项目更有优势呢？我们可以百度下架构的演进，就会有一系列文章对项目架构

从单体到当下流行的架构做介绍，我想说：我们项目的初衷是什么，是使用流行的架构，还是解决

 某类问题呢？考虑到这点，我更倾向于后者。

        我的项目是充电桩运营项目，包含了公众号、PC管理端、第三方API接入和充电桩通讯端。

从最初多个语言小系统合并成了一个系统，这么做的主要目的是统一项目的技术栈、减少后期

人员流动造成的项目风险，但单体项目运行久了，随着业务功能的完善，充电桩接入量的上升

个人觉得每次部署项目启动项目，对项目依赖太大了，每次改动代码都小心翼翼，怕后面的改动

影响其他功能业务逻辑，因此项目拆分很有必要。

        按照业务拆分、功能拆分、拆分要到什么粒度、我目前根据当下情况，只拆分充电桩通讯

端、因为拆分该端口，会大大提高充电桩接入量，在增加协议的同时，不用担心用户端的问题，

之间通讯问题可以引入消息中间件、Redis队列、或者采用数据库任务方式解耦、目前我选择数

据库任务方式接入。

         业务拆分遇到的主要问题就是系统之间的缓存存储问题，如果是单点存储，在分布式调用

过程中，因为调用的不确定性质，就肯定导致无法命中存储的服务，所以，精准的命中该存储的

服务才是调用之间的关键所在。比如 系统Socket连接的存储、用户Session的存储等这些有状态

的存储，一般都可以通过Redis解决，Redis毕竟是一种中央缓存大家都用。一些问题定时任务也

可以解决，因为定时任务的选取，可以选择本地缓存存储的那些事件，这点就是把业务准确分摊

到每个服务节点。

        拆分的另一个问题就是代码规范，别拆分了代码之后便复杂了，一种方式互不相相干，你干

你的事情，我不参合，你改你的，我就是不改，这样的方式就跟单项目差不多，很大几率造成一

个差不多的实体类多个版本，一种方式抽取公共的，但该方式就会大几率的造成同时部署，否则

一些微服务调用版本字段不对影响调用，各有优缺点。