BridgeLi's Blog

今年年中的时候由公司平台部转组到Alpha项目中心负责公司一拍项目组的技术研发工作，到现在已经快有将近半年的时间了，随着对系统的越来越熟悉，对原有系统的架构也越来越感到有些不合理的地方，随着自己水平的提升感觉对架构也有了一点自己的理解，所以今天就借这个机会说说自己的不成熟的建议。

一. 原有的架构

俗话说，一图胜千言，直接上图：

解释一下这几个系统分别的作用：
1. 后台管理系统不用说了，管理C和B可见的内容；
2. C端用户系统，是对C可见的一个系统，一拍是一个招聘系统，所以就是对候选人操作的后台；
3. B端用户系统，是对B可见的一个系统，通俗点讲就是HR操作的后台；
4. Dubbo系统，是对兄弟部门和B提供服务的一个系统；
5. Recommend系统，其实也是一个Dubbo系统，区别在于Dubbo系统是对外提供各种服务的，而Recommend系统是发现全站系统用户的行为，然后对用户的行为进行分析，甄选出一部分C端用户作为一拍的现在用户；
6. msgpush系统，是用netty做的一个实时消息推送的IM服务，目前主要是给后台管理用户和C端候选人聊天的一个系统；

其中：1. 在我们接手之前B和C是同一个系统，也就是说B是我们这半年新加的一个系统；2. Recommend和msgpush系统也同样是我们这半年新增的一个系统

二. 系统架构存在的问题

目前后台管理系统、C端用户系统、Dubbo系统各自独立，这样存在的问题：

1. 最主要的是各自分别操作数据库，这样只要底层数据库发送变动，那么三个系统操作数据库的地方都要同步修改三次；
2. 操作数据库的地方代码冗余，很多地方都一样，这样一个地方出bug，三个地方要同步修改，然后都要上线；
3. 后台管理系统采用分层的模式分模块而不是根据业务分模块，这样每次上线service和dao都要先deploy jar到maven私服；
4. 当时为了快速迭代，Recommend系统也是单独操作操作数据库，不过还好用了后台管理系统的dao这个jar包，但是首先根本不需要这么重的一个jar包，其次jar出bug了，有时候他也需要重新上线啊，不然这个jar包就会一直很旧，当然只要不涉及到他操作数据库的地方出bug，你不改也是可以的；
5. 目前C和B虽然已经分开，但如果用户激增，横向扩展依然不合理，只能整体加机器，而不能针对性对某些模块单独加机器；

6. 代码中存在的问题：不知道什么原因大量的逻辑被写在了controller层，导致代码可复用性差；
7. 由于之前后台管理系统和其他系统不是同一个团队开发的，命名各有各的风格，代码不仅冗余还同样一个类名字不一样；
8. 很多系统日志配置的也有问题，错误日志和最基本的业务日志没有区分开，目前在将就用；
9. 系统中的jar依赖不仅存在循环依赖，而且加入了大量的自己不需要的依赖，导致各种jar冲突出问题；

综合以上问题，我个人认为这是一个：可维护性、可扩展性不高的系统。

三. 我的个人思考

同样先来一张图，来总体说明一下我的想法：

整体来说只有相对独立的实时消息推送系统不懂，然后把其余的各个业务层抽象成微服务，采用公司目前使用比较成熟的dubbo作为rpc框架，controller层只负责业务转发不负责逻辑的一个简单系统，这样带来的好处：

1. Dubbo系统作为核心的业务系统，分别对兄弟部门、后台管理系统、C端用户系统、B端用户系统、Recommend系统提供服务，如果用户量增加，不仅可以整体增加Dubbo系统的机器，也可以把调用量大的接口单独拆出来，部署到另外的机器上，实现隔离，不会因某个接口调用量大，导致整个系统不可用，而且把数据库的底层操作也放到了这个Dubbo系统中，这样就可以避免数据库修改，要修改多处的问题；
2. 抽象出来的这个dubbo系统，不仅可以解决后台系统和其他系统命名不一样的问题，而且和可以解决不同团队造成的coding style不一的问题，一举多得；
3. 由于后台管理系统、C端用户系统、B端用户系统、Recommend系统都调用Dubbo系统，所以他们的controller层讲极其简单，很多业务逻辑类似的东西全部放到了Dubbo系统里面，代码的可复用性提高了不少；
4. 抽象出来的逻辑都统一放到了dubbo中，这样系统如果有bug，这样就做到了一个地方修改，这样多个地方就可以同时生效；
5. 由于业务都在Dubbo系统里面这样同时也避免了曾经出现了，后台管理系统和BC系统使用的缓存不一致，导致缓存出问题的这种低级bug；
6. 由于controller层简单没有逻辑，这样就可以避免目前由于后台管理系统单机，修改一个业务逻辑bug重启系统，导致后台不可用的问题，因为只需要重启dubbo就行了；
7. 这样controller层变得很轻，只需要一个简单的servlet容器，对机器的要求会降低不少；

四. 备注

由于我工作时间不长，见过的系统更有限，所以对系统架构几乎没有什么经验，这些只是我个人的一点很粗浅的理解，例如把dubbo做的那么重，虽然可扩展性提高了不少，但其实也不知道算不算合理，因为调用rpc服务，肯定会增加网络IO延时，所以这些算是我个人的抛砖引玉吧，一方面希望对同样和我一样没有经验的小伙伴能有所帮助，另一方面希望有经验的小伙伴能留言交流

五. 总结

以上便是我个人对拉勾一拍所有的核心系统进行了审视后的一番分析，如果这些核心系统架构的重构真的达到自己的理想状况这将是一番浩大的工程，对于高速发展的互联网公司来说，这就是一边驾驶者一辆高速前进的汽车，一边对这辆汽车进行换轮胎换发动机，先不说工作量的问题，难度程度也可见一斑。