对一个“老”架构的从新思考

前言

五年前，我在CNBLOG写的一篇文章，《php+mysql下，对网站架构方面的一些认识（以我维护的站点为例）》，固然，整套架构不是作的，而是配合当初的运维部门，共同完成。那个时候我从入行PHP两年，对所谓的“架构”也是懵懂。只以为很深奥，很高大上。那时候，架构师，那简直就是神通常的职位。

当时，这篇文章被不少站点收录，诸如：51CTO、CSDN等这样的大站，也有不少小站。不过文章中，我已经去掉了不少的配图，由于可能涉及到安全因素。在当时看，架构仍是蛮不错的。可是也存在较多问题。

放眼如今，咱们能够从新整理这套架构

• 找到能够优化的地方

• 找到替代的方案

须要思考地方

咱们先来看下架构图：

从上图，咱们分两大部分，分析：

• 左侧的程序代码同步

• 右侧的架构

如何优化

现有作法：

从版本管理工具拉取最新代码，除去.svn标记等文件，同步到生产环境

svn拉取最新代码 -> 测试服务器 -->rsync同步--> 生产环境

存在的问题：

一、采用svn进行版本管理，不利于团队协做开发；常常会出现修改的文件又被以前的覆盖了，白作了

二、在项目较大的状况下，全部的资源控制系统都是把文件的元信息隐藏在一个相似.svn，这个.svn文件会巨大，
svn是按照文件进行比较的，会占用很大资源

进一步优化：

使用SVN进行版本管理，和程序发布，不方便进行测试环境和生产环境的代码区分，麻烦点，能够解决

trunk->tag

trunk的发布到测试环境

tag的发布到生产环境

tag的程序均是通过测试经过的，由trunk合并过来的

最优方案：

采用git版本管理工具

svn 与 git 的区别

• 最核心的区别Git是分布式的，而Svn不是分布的。svn必须联网进行操做。好处是跟其余同事不会有太多的冲突，本身写的代码放在本身电脑上，一段时间后再提交、合并，也能够不用联网在本地提交。

• GIT把内容按元数据方式存储，而SVN是按文件。你会发现有个.svn 这个文件会愈来愈大。

• GIT分支和SVN的分支不一样。分支在svn中并不突出。常见的就是branch，它是一个完整的目录。而git的特征就是分支。

SVN的特色是简单，使用一个中央版本库。

Git的对分支和合并有更好的支持,这是开发者最关心的。

具体作法：

一、创建两个分支：master 和 develop
二、master用于生产环境，develop用户测试环境。
三、master分支禁止被提交（commit、push），只准从develop或hotfix（线上bug）合并而来。
四、服务器上写一个shell脚本，用来作两件事，一是拉取最新代码，而是rsync同步代码

剩下的是团队成员开发协做、以及发布流程相关问题。

一、如何协做开发？参考这篇文章 Git 在团队中的最佳实践--如何正确使用Git Flow，写的很不错。不少公司在此基础上进行优化和改进

二、发布流程，我这里草拟了一份，增长了一个pre_product预发布分支。可能在你公司就不适合，请酌情调整。

咱们用的是Teambition项目管理工具，能够新建个TAB，如：opend、working on、pull request、review、

merged、done。任务有技术负责人下发，成员认领开发。

代码审查

你Google一下Code Reivew这个关键词，你就会发现Code Review的好处基本上是不存在争议的，有不少不少的文章和博文都在说Code Review的重要性，怎么作会更好，并且不少公司在面试过程当中会加入“Code Review”的问题。

可是，咱们常常会遇到这种状况：

1）工期压得太紧，时间连coding都不够，以上线为目的，

2）需求老变，代码的生命周期过短。因此，写好的代码没有任何意义，烂就烂吧，反正与绩效无关。

其实，我认为这是很不负责任的。后面，咱们会用大量时间来解决以前本不应发生的问题。

架构优化

LVS部分可使用nginx的反向代理去实现，道理与LVS相同。用户请求到代理服务器，nginx代理服务器分发请求到后端WEB,我找了个图，方便你们去理解

nginx特色

nginx性能好，承担高的负载压力且稳定，能够负载超过1万的并发。

工做在网络的7层之上，能够针对http应用作一些分流的策略，好比针对域名、目录结构；

Nginx对网络的依赖比较小；

Nginx安装和配置比较简单，测试起来比较方便；

Nginx对请求的异步处理能够帮助节点服务器减轻负载；

LVS的特色

抗负载能力强、是工做在网络4层之上仅做分发之用，没有流量的产生；

配置性比较低，这是一个缺点也是一个优势，由于没有可太多配置的东西，因此并不须要太多接触，大大减小了人为出错的概率；

工做稳定，自身有完整的双机热备方案；

无流量，保证了均衡器IO的性能不会收到大流量的影响；

LVS须要向IDC多申请一个IP来作Visual IP，所以须要必定的网络知识，因此对操做人的要求比较高；

具体看你的业务状况，使用nginx或者lvs。当初公司的日均PV均超过100W，因此采用的是LVS方案+双机热备

集群优化

架构图上是两主两从MMM （Master-Masterreplication manager for MySQL）。其实很长状况下，是一主三从模式。只有在master1宕机的状况下，才启用master2。

主从复制

MySQL复制基于主服务器在二进制日志中跟踪全部对数据库的更改(更新、删除等等)。所以，要进行复制，必须在主服务器上启用二进制日志。

每一个从服务器从主服务器接收主服务器已经记录到其二进制日志的保存的更新，以便从服务器能够对其数据拷贝执行相同的更新。

从架构图中咱们能够分析，在大并发量较大的状况下，会出现主从复制延迟这种问题，如何解决？目前已经有了比较成熟的方案。

主从复制原理图：

步骤1： 全部数据更新都会被主库记录到主库的二进制日志。

步骤2： 与此同时从库的IO线程会从主库上读取二进制日志，写入到从库的中继日志上。

步骤3： 从库的SQL线程读取中继日志上的内容来更新从库。

形成延迟的缘由

一、并发较大的状况下，master产生的DDL和DML数量大于salve的可接受数。从库的Slave_SQL_Running是单线程做业，不能并发执行，因此当主库的TPS并发较高时，就容易产生延迟。

二、slave将主库的DDL和DML操做在slave实施。DML和DDL的IO操做是随即的，不是顺序的，成本高不少，还可能可slave上的其余查询产生lock争用，因此一个DDL卡主了，须要执行10分钟，那么全部以后的DDL会等待这个DDL执行完才会继续执行，这就致使了延时

如何解决

一、减小slave同步延时的方案就是在架构上作优化，尽可能让主库的DDL快速执行

二、主库写对数据安全性较高，好比sync_binlog=1，innodb_flush_log_at_trx_commit = 1 之类的设置，而slave则不须要这么高的数据安全，彻底能够将sync_binlog设置为0或者关闭binlog，innodb_flushlog也能够设置为0来提升sql的执行效率

三、使用比主库更好的硬件设备做为slave

四、使用mysql5.7 参看 《MySQL 5.7 并行复制实现原理与调优》

分库分表

这篇文章写的很好，须要好好拜读

http://www.cnblogs.com/hackxh...

以上是对几年前的架构进行能够优化的地方