标签：
互联网的业务千差万别，不同的业务分解下来有不同的系统，所以业务层没有办法提炼一些公共的系统或者组件，但抛开业务的差异，各个互联网业务发展最终面临的问题都是类似的：就是复杂度越来越高，也就是说，业务层面对的主要技术挑战是“复杂性”。
幸运的是，面对业务层的技术挑战，我们有一把屠龙宝刀，神挡杀神，佛挡杀佛，不管什么业务难题，用上屠龙宝刀一试都迎刃而解。这把屠龙宝刀就是“拆”。
复杂性的一个主要原因就是系统越来越庞大，业务越来越多，降低复杂性最好的方式就是“拆”，化整为零、分而治之，将整体复杂性分散到多个子业务或者子系统里面去。
以一个简单的电商系统为例：
如上图，我们这个模拟的电商系统经历了3个发展阶段：
第一阶段：所有功能都在1个系统里面
第二阶段：将商品和订单拆分到2个子系统里面
第三阶段：商品子系统和订单子系统分别拆分成了更小的3个子系统
以上只是样例，实际上随着业务的发展，子系统会越来越多，据说淘宝内部大大小小的已经有成百上千的子系统了。
虽然说“拆”是屠龙宝刀，但也不能乱拆，拆到合适的粒度是一门艺术，拆的太粗复杂度没有降低，但也不是意味着拆的越细越好，主要原因如下：
1）子系统太多，运维成本会增加，包括系统资源增加、问题定位复杂度增加
2）子系统太多，开发成本可能会增加，例如做一个需求可能要10几个系统配合
3）子系统太多，子系统的交互又会越来越复杂，单个系统的复杂度降低，但整体的复杂度还是会升高。
我们之前有业务一开始上来就拆了40多个子系统，开发过程中很蛋疼（测试和分工），上线后更蛋疼（上一个功能要10多个系统一起上版本），后来受不了了，1年以后开始将很多系统合并，慢慢的将系统数量减为不到20个。
我个人的经验就是7+-2原则，也就是说将系统拆分为5 ~ 9 个人能够维护的粒度，也就是说假如你的团队有20人，拆分成3 ~ 5个系统是比较合适，即使再拆的更细，最低要保证3个人负责一个系统的粒度，如果出现一个人负责1个系统，甚至一个人要负责多个系统，就说明拆的太细了，会带来很多问题。
为何按照这个原则来拆分呢？科学研究证明，人脑同时关注的目标大约就是7+-2个，对于一个9个人负责的系统来说，每个人都可以覆盖到系统的所有方面，如果20个人才能维护一个系统，说明1个人可能要关注20个点，但人很难关注这么多的点的。
其次为何至少要3个人负责一个系统呢？这是从团队管理的角度出发的，如果2个人甚至1个人负责一个系统，首先是人员没有足够备份，一个人请假或者变动，整个系统的效率就要受到影响；其次如果1个人负责一个或者多个系统，思考难免有遗漏，容易出问题。
除了拆分的粒度需要关注外，运维的配套也需要特别关注，因为不管怎么拆，系统数量肯定是比以前多了很多，如果按照原始的人工敲命令的方式进行运维，难以支撑不断增长的系统数量，就会出现运维每天16小时都在执行升级部署和问题处理。
基本的运维配套如下：
1）部署：自动化或者半自动化的部署，避免运维人员执行shell命令或者脚本的方式去部署
2）日志采集：需要统一的日志采集系统，将多个系统的日志聚合在一个地方，方便出问题的时候快速定位问题
3）监控：需要建立统一的监控平台监控各个子系统
标签：
原文地址：http://blog.csdn.net/yunhua_lee/article/details/51283414
