45 | 架构重构内功心法第一式：有的放矢

思考了下当前负责的系统，感觉更多的是需要优化而不是重构，主要原因是如果从新来过还是会采用当前的结构，只是功能需要进一步完善和改进。 之前做过一次缓存架构的重构（自认为的）：我们的系统是3地5中心的部署架构，我们数据的写入是固定在一个机房进行单点写入，然后同步到其他的集群去，db层面的同步是通过数据库自身的主从同步机制实现的；而缓存的同步则是通过消息中间件来进行的，写入集群发送消息，其他集群接收消息而后写入到各地的缓存集群中。写入时是db写入成功就认为写入成功，返回调用方成功。这种实现方式虽然有数据同步延迟和少量的缓存db数据不一致，但对于绝大多数场景都是可以接受。 后来随着业务的发展，出现了写入后立即读的场景（读和写不在同城）,并且不允许读到的数据和写入的数据不一致。在这种情况下原有的缓存更新机制就有问题了：db写入成功缓存消息处理失败或者读请求时消息还没有到达异地机房，这时都会导致缓存和db数据不一致，引起业务异常。 面对此种场景，最初提出的解决方案是让业务方在调用写服务成功后再调用读服务，如果读到的数据和写入的数据一致才进行后续的操作，但这种方案实现总体成本比较高：如果有5个调用方，5个调用方都需要这样修改，重复工作，并且做了不需要自己关注的内容；同时在调用读请求时还要考虑重试机制，实现方案也有些复杂。这个方案提出来后没有一个调用方按照这个做的。 后面进行review的时候决定还是应该自己来做这件事，对外屏蔽复杂性。因而对这一块进行了重构：将缓存内容根据缓存key按照一定的规则进行分区存储，对于实时性和一致性要求高的数据采取同步写缓存操作，如果缓存写失败，直接返回业务方本次写操作失败，由业务方重试。同时本地发送一个删除缓存的消息，异步将缓存删除，确保之后有机会从db中读取最新的数据。这样改造完成后，整体的请求耗时（因为要跨区同步写缓存）和业务失败率有所增加，但满足业务方的需求。 这个改造简要而言是将业务从pa模式改为了pc模式。

系统优化，我们公司就是一个字，拆，拆数据库，拆服务，没有依赖就没有伤害

总之，架构重构需要架构师既要说得动老板，也要镇得住同事；既要技术攻关，又要协调资源；既要保证业务正常发展，又要在指定时间内完成目标……总之就是十八般武艺要样样精通。 老师，这些都是架构师的软技能吧？市场上的课都偏技术，可以讲讲这些吗？谢谢

老师您好，我们现在面临一个运行18年的.net业务系统，业务一刻不能停止，大约2000张oracle表，大量的存储过程函数等实现的业务逻辑，现在要用java来重构，面临的问题就是好多大表都在Oracle中，想去o就涉及到很多表关联，做不到垂直拆分，业务耦合太紧，您有什么好的建议或者我们该从哪方面切入？

我公司正巧在重构系统。定期3个月。电商系统。原来是dubbo 服务间调用 ，redis 缓存，mysql，模块化开发，云平台,svn。问题，关联查询太多，dubbo部署的相关模块太多，业务复杂度太高，业务调用同步慢，一搞活动，数据库就爆，业务逻辑懂的人换了一茬又一茬。目标spring cloud,docker,k8s,git,禁止关联查询即单表，解藕慢操作即异步，接口细粒度，层次调用分明，服务隔离能缓存就缓存，业务大拆解。最终会是什么样，静待。学了老师这么多，手术台上实习了，哈哈. 缓存，异步，事务消息最终一致，强制单表查询，业务边界，规范。牵一发动全身，业务等待，加班加班……

老师，我们现在公司遇到的问题和你说的X系统很相似，现在也在逐步将那些热门业务做成微服务，拆分出去，但是涉及到的数据表，拆到其它RDS上去，涉及到的跨库查询很麻烦。现在只能做成接口了

当前的系统刚刚做过一次重构，当时选择重构的原因有这么几个，原系统有一个大的面向客户的web系统和多个单独的进程组成，前后端在一个war包，后端服务单机远行，两者通过db交换数据。问题有这么几个，web系统累积了5年的代码，改个bug已经随时搞挂整个web端。后端服务单点问题。数据库压力很大，一个功能的sql拖垮整个库。 重构的思路是，先将单体后端进程服务化，服务化过程中非核心数据从主表分离出来。web系统结构不动，上线一个服务就从原来的查db改成调用服务。服务梳理差不多了将web端重新实现前后端分离。做完这些后将数据库结构重新设计。总的来说跟文中的第三个例子有点像。

我们系统目前的瓶颈在数据存储，之前数据的存储都是oracle加上redis做缓存。现在活跃用户在500万左右。拿卡券业务来说，每个月产生的优惠券数量都在6000万左右，导致现在需要运维每两个月就要对表做瘦身，并且前端用户也只能查询两个月内的卡券。 目前讨论的技术方案是使用mycat做分库分表，数据库使用mysql。遇到的问题有事务控制的问题，典型的就是卡券转赠，之前在oracle就直接利用数据库事务就可以解决。现在由于转赠记录和受赠记录不会落在同一个库，所以需要程序做策略来保证最终一致性。

架构师的要求好高啊，既要对业务非常熟悉，也能精通各种技术，其次还要能hold住人心。

目前系统采用类似微服务模式。如有1后台管理，2商家pc后台，3商家app接口服务，4server，都是独立部署。前面的1 2 3都依赖4。目前的问题是1也会访问数据库，server也访问数据库，有一部分重复。2 和3 也有重复逻辑。目前一个小需求，都可能要改多个端，由多个人介入，开发成本比较高。 近期准备重构，使用多模块形式来聚合工程，提取公用服务，但会保留现有独立部署模式，以此来达到提效的目的:-O