单例服务拆分为分布式架构

将独立业务服务拆分为分布式

为啥会有这个想法？因为我要造锤子，拿着造好的锤子，去找锤子，没有造锤子的经验无法找一个造锤子的坑。

现有情况说明，说明睡觉😪

单机软件：就是将软件安装在自己的电脑上，自己用的那种，这个需要拆分分布式么？答：完全不要的那种。
现有业务：软件主要是做模型开发，然后在一定条件下计算这个模型，针对各种情况计算出一定的概率值。
现有架构主要框架构成：springboot、mybatis、Mysql、webSocket（客户端有数据缓存需要及时告知其他客户端）、activemq（主要用于和计算引擎交互）。

做了一个美梦，梦中就是一顿乱锤，80，80，80…

• 业务拆分： 尽可能保证业务独立，当然有时拆的太新，就把自己累死了，比如我，我就一个那这造🔨找🔨的人，所以大锤80来一下就成两半了，一个模型构建，剩下的就是其它。
• 业务升级：保证服务可用性，针对重要的业务服务，最好做到无状态，扩展上就可以用。模型构建的业务水平在来一个80，一个变两个。一个不顶用的时候，另外一个接上，像极了失恋的你，满世界寻找另外一个它安慰自己。
• 框架解耦，轻量化：拆分后，每个微服务…哎呀,刚刚在梦中被踹了一下。（不会吹了）
• 数据独立：降低模块数据的复杂度，每个微服务尽可能减少业务间联系，如果比需要尽可能异步处理，实在不行，就把最后一个80给产品。

梦醒了，戏精开始整活

目标：高大上，最求13.
不管好不好用，来一堆框架，什么spring全家桶、主从数据库、openFeign、getway、nacos、redis、CI/CD通通上。
花一秒思考一下：

• 主从数据库：保证数据库高可用，万一有个内存或者磁盘满了，还有一个可用。至于从节点是只读还是读写，我们这款软件不用考虑。
• openFeign：远程调用（RPC），不用自己的写请求调用的接口看起来就很厉害的样子，如果有以后，那么以后在横向扩展的时候，就不用自己配置节点的信息。（当然也可以直接将接口发送到网关由网关转发，有时网关会检查用户信息，这样就需要做排除，麻烦！！！）
• getway：网关，用来转发请求和webSocket消息；写一些拦截器做些信息检查，鉴权等；配置请求转发规则；熔灾降级等，网上说zuul转发webSocket的机制不太好。
• nacos：都上分布式了，没有一个配置中心恐怕这个13有点low，当然注册中心这个也是必须要的，所以来个nacos。
• redis：都是分布式了，有很多java中原来使用的锁，以及线程安全的变量也要替换一下。还好单机版的redis可以保证原子性。
• docker：都分布式了，是用docker配置相关环境easy
• jenkins：都分布式了，添加多台实例的时候，还要打包部署太麻烦，不如来个CI/CD

趁梦还在有效期，拿个小本本记录下来

整上心中预想的架构图：

改造过程中遇到的问题点

• 原来业务有数据初始化和定时任务，横向处理完后，需要注意这样业务，是否要指定机器完成
• webSocket消息经过消息处理中心后，需要调用模型构建服务，此时OpenFeign需要携带用户信息，此时用户信息需要添加到api中。
• 用户的登录的处理，放到getway中还是模型构建服务中。
• 业务服务中，如果有读写公共资源的，需要加锁或者使用缓存处理。（读写磁盘文件，需要对文件获取锁；对于原有的java中的锁和线程安全类需要使用redis处理）
• 主从数据库，拆分主从后，从节点负责读取，在代码中如何便捷实现；主节点挂了之后，如何让之后的curd发送到从节点。
• 关于用户信息的存储方式，是存放到缓存中还是header中。
• 静态资源：项目中存在重定向的页面，打开之后会到定向的模型构建服务中的某一个服务中且ip地址也是该服务的ip此时，例如：原来请求的是http://127.0.0.1:8080/login.html，经过重定向后编程了http://192.168.50.121:8082/xxxx，这样之后的请求都会走8082的服务。
• 请求会发生跨域的问题。
• springboot、springcloub、nacos的版本适配。
• 原先单体的Junit单元测试案例，如果接口涉及到OpenFegin的话可能需要额外处理。