2016年12月31日
最后一天，一直想写关于技术方面的总结和屡屡工作成果，觉得没有什么高深或是拿的上台面的技术方向的突破。一直拖着没开写，最后一天，如果再不写，这一年就过去了。还是那句话，写出来就对了。
主要还是关于工作上一年忙活出来的成果和经验之谈，对互联网软件公司业务架构有从1.0向2.0或3.0的转变的还是有些帮助滴。
公司技术背景：公司本身有自己的快速开发平台，用以维持产品的需求迭代。随着公司发展，这套架构越来越重，以下有几点突出的缺陷：
业务迭代导致业务异常复杂，程序猿业务水平要求越来越高。
历史包袱沉重，系统耦合非常严，bug频发无法定位，不够稳定。
非高可用：既然是单点，master一旦发生故障，服务就会受到影响。
性能瓶颈：既然是单点，不具备良好的扩展性，服务性能总有一个上限，这个单点的性能上限往往就是整个系统的性能上限，即使用服务器堆也是无法解决的。例如：数据库的主从延迟，服务器一个出现问题，整个系统骨牌效应等。
业务支持不够灵活，开发迭代不够快速。开发测试及发布项目操作繁复。
同大多数互联网公司一样，也是到“拆”字的阶段了。也进行了“拆”的好处和步骤的讨论和分析。
但是，首先，咱们在“拆”之前还要先了解了解公司在没有互联网分布式开发思维的前提下，是怎么来解决上面的问题的，这里面也有很多值得分析和总结的地方。
1、单体结构的扩展问题当下解决方案。
这种传统的web工程大家都很熟悉，当系统运行过程中，通过监控程序发现，Module A 与 Module B 都需要消耗 10% 的系统资源，加起来才占总系统资源的 20%，而 Module C 却要占用 80% 的系统资源。运行一段时间后，Module C 就会成为整个系统的瓶颈，从而将会降低系统的性能。
那么，如何才能解决这类问题呢？想到了一个简单的办法。水平扩展
只需将这个应用程序复制一份，一模一样的程序，将其部署到另一台 Web Server 上，下方还是连接到同样的 Database，只是在这些 Web Server 的上方架设一台 Load Balancer（负载均衡器，简称 LB）。请求会首先发送到 LB 上，通过 LB 上的路由算法（例如轮询或哈希），将请求转发到后面具体的 Web Server 上，这类请求转发技术被称为 Reverse Proxy（反向代理）。
由于进入 LB 的请求（流量）被均衡到下方各台 Web Server 中了，流量得到了分摊，负载得到了均衡，因此该技术也称为 Load Balance（负载均衡）。如果流量加大，我们还可以继续水平扩展更多的 Web Server，该架构理论上可以无限扩展，只要 LB 扛得住巨大的流量就行。
通过以上技术方案，轻松地将负载进行了均衡，一定程度上缓解了流量对 Web Server 的压力，但此时却造成了大量的系统资源浪费，比如对系统资源暂用率不高的 Module A 与 Module B 也进行了水平扩展，其实我们真心只想对 Module C 进行水平扩展而已。
这个时候，我们又有了新的灵感了，如果通过hosts域名进行按模块分配域名来进行部署。就是说当订单模块需要发布新需求和bug的时候，只针对订单模块分配的域名机器进行发布war包。这样是不是说就可以解决，系统资源的浪费呢？好吧，如果你能记得住，这个订单模块下的支付代码修改过了，然后支付模块分配的域名服务也需要进行更新，然后结算模块代码也需要更新。。然后。。。。，希望运维能够坚强。
突出表现为：系统资源浪费、部署效率太低、技术选型单一
2、数据库的扩展目前解决方案
对千万级别大表进行了分库分表操作。
虽然考虑到业务表太大，进行了大表分库，单表取模等拆成多表。可是由于没有业务解耦，架构拆分分布式的思维，分库是根据业务表大小进行的，导致同一模块不同库，不同模块却共库。这个时候事务的一致性无法保障，对金额等强一致的业务无法给予充分的同步。
也进行了主从分离的操作，目前可以做到一主多从库的方案。
有的库是一主多从，有的是一主一丛，不是动态分配读库，而是根据服务器Hosts来分配这台服务对应的从库。这个完全不考虑高可用的数据库方案，希望数据库瓶颈来的更晚一些。
以上两种现实，也就造就了，公司对运维团队的素质和要求就比较高，相对同类型公司，运维团队较值班工作繁重。
**********************************************************************************************************************
上面已经对现有公司现状进行了分析描述，也就更加充分明确了为什么要“拆”了。下面咱们来聊聊怎么来解决上面的问题。（前提：重构目前开发投入2个人）
多次讨论后，拆分历程分为三个步骤：
业务系统垂直拆分。模块化（评论，支付，用户…）, 数据 & 业务模型统一，服务接口设计逻辑清晰，粒度合适, 基础业务逻辑下沉到服务，Web 层专注表示逻辑和编排
DB 垂直拆分。对现有的业务代码重构后，需要对Server层数据获取进行重构并且按模块进行分主从。设计好接口api, 避免web层做出较大改动。
在非核心流程拆分出来后，线上完成分布式事务一致性架构稳定后，进行大批人员投入，进行整体的流程相匹配的开发管理和工具。
这里面有个问题，解耦应该是先从db拆分开始，为什么要业务代码先开刀，数据库不做变更呢。这里面就是公司的管理层没有互联网分布式架构的经验，不是很了解相关互联网分布式开发和架构，属于摸着石头过河的策略，对于公司为什么不大量引进互联网开发人员这里就不做讨论了。
历程一业务拆分：
系统拆分的优先顺序，优先非核心业务。在重构中将代码功能分成了一级功能，二级功能和三级功能。业务分级是将不用影响最终结果的业务剥离出去，将最核心的业务重点对待，不同级别用不同的处理方式。
系统架构分层。后期希望是分三层，web、biz、server层，目前只是进行了web+biz、server层这2个工程用dubbo进行rpc调用。web这边做相关的通用拦截功能校验(md5、禁词、黑名单等)和返回视图拼装，server进行数据库的相关操作。
系统持久化的同步。由于是线上和重构同时进行，必然会有缓存的解决方案不一致memcache 和 redis 的兼容性。数据库的主不一致，新老系统之间的交互等问题需要解决
历程一这块第一个步骤业务拆分分级这个根据各个公司有各种自己的方案，不多说，咱们主要聊聊第二、第三步这两步是具体怎么实现的。
系统分层讨论：网络上大家对系统分层的主要分歧，大多是在web/biz/server这几个层次分的不一致。有的认为应该各层独立服务分3层、也有的考虑分两层(web+biz/server)、最后比较多的支持一个war包一个工程。在我看来，这几种方案针对数据量、并发量、业务复杂度来确定自己公司的架构层次。
web层：目前公司这边主要因为业务线过多，考虑到web层展示的复杂，分为两层(web+biz/server)。 （其实这块个人还是有些想法的，针对公司线上的并发量及多种缓存共用和序列化传输等情况，还是倾向于单war的项目）
server层：services的考量是根据业务的复杂度来进行单service还是多个子功能模块services。
总的来说，细粒度拆分的优点有：
（1）服务都能够独立部署
（2）扩容和缩容方便，有利于提高资源利用率
（3）拆得越细，耦合相对会减小
（4）拆得越细，容错相对会更好，一个服务出问题不影响其他服务
（5）扩展性更好
（6）…
细粒度拆分的不足也很明显：
（1）拆得越细，系统越复杂
（2）系统之间的依赖关系也更复杂
（3）运维复杂度提升
（4）监控更加复杂
（5）出问题时定位问题更难
（6）…
系统持久层讨论：上面已经说了前提是一两个人在做架构重构，所以第一步是先分级，非核心业务进行了拆分，导致库和缓存还是要和老系统共用。老系统对数据的增删改，新系统都需要进行同步，老系统也需要考虑新系统的数据更新。这些缓存的同步实现属于过渡期间的非业务代码，借鉴了其他公司在这方面的先例，引进了canal框架服务。通过主库的binlog日志进行主从同步，这边来同步新老系统的缓存。数据库的考虑可以参照《36条mysql军规》等等。
历程二DB垂直拆分：
.
原文：http://www.cnblogs.com/xiaolailai/p/6241444.html