前言
最近一年半多一直在做一个CMS项目，做了快两年了也没有上线，而且开发还走了不少，其中有不少原因是因为开发中频繁改动需求导致开发人员失去耐心，但是其中还有一个重要的原因就是架构设计的不好，导致很多服务的边界很模糊，耦合性强，改一处需求从而导致迁一发动全身的恶果！下面复盘下这个项目中架构设计的坑，从中吸取教训！
架构图
首先，这个项目采用的SOA的架构，分为多媒体、广告、任务调度、核心这四个模块，其中核心这个模块定义的很模糊，把认证、授权、站群全部放在的核心模块中，这样导致核心模块成了一个臃肿的单体服务。
多媒体模块：负责图片、视频、文件资源的上传下载，需要视频转码、图片处理时则调用task模块负责，task处理完成后再通过mq回调core通知任务处理成功。
广告模块：负责接入大数据便签，通过大数据推送的人物画像标签动态生成广告，实现千人千页广告效果（广告模块的理想状态下的功能，实质上有各种原因没有实现‘千人千页’的效果，后面会具体说下原因）
调度模块：负责处理多媒体的图片、视频，站群的发布任务（这个模块的服务边界很模糊，导致调度模块过多耦合业务最终成了一个谁也说不清楚的烂摊子服务……）
核心模块：这个模块同样存在服务边界模糊的问题，核心模块里面有包含了用户模块、站群站点模块、OpenApi模块，最终结果就是一个四不像的单体应用……
通过上面的描述，其实发现一最大的问题就是模块之间服务边界很模糊，大家谁也说不清楚这个模块到底是一个工具模块（调度模块）还是一个业务模块，开发者不清楚那些逻辑要写在core里面，那些逻辑是要交给task里面，再加上开发者的水平也参差不齐，对业务和架构理解不透彻，架构师也没有及时的codeview（或者说，架构师自己对模块之间的服务边界问题也很模糊），最终的结果就是大家没有统一的开发原则，自己的代码想写在那个模块就写到哪个模块中，时间长了连开发者自己也不清楚一个业务到底有哪个几个模块参与了或者自己捋不清楚自己负责的业务线（当然，这里还有一种可能，就是模块之间的服务边界很模糊，有些开发者可能为了偷懒强行把一个业务部分逻辑放在其他模块中，让别人替自己实现，美其曰，这是按照模块开发的思想，其实这本质是一种不负责的表现！）。
优化后的架构
优化后的架构还是SOA架构，把核心模块拆分成了用户模块、站群站点模块，调度模块里面的业务逻辑迁移到业务层中，从此调度模块不再负责业务处理，只负责任务的调度，所有的业务代码全部放在业务层中，生命周期也全部在业务层中。
这里强调一下，之前的调度模块里面有业务代码，所有有些业务的生命周期是跨模块的，这样会导致业务线不完整，或者耦合很大。调整后的调度模块，只服务调度任务，任务的的具体实现是由发起调度任务的开发者实现，即：谁调度谁实现，这样的好处有两点，一是调度模块由业务模块转变成了工具模块，解耦合，二是业务代码的生命周期完全在业务层中，不会再出现一个业务线开发者自己都捋不清楚的情况发生，即：谁开发谁掌握代码的生命周期。具体调度模块怎么调度任务，这里有很很多的实现方式，rest、rpc都可以实现，完全没有必要通过MQ来调度任务。
最后吐个槽，一个合格的架构师一定是一直保持在一线码代码的高级工程师，如果只会ppt不能技术落地这样会害死人的……
