Upyun运维大会之分享

上个月参加了upyun运维与架构交流大会，自己在做运维之前不曾参加过这样的会议，参加之后发现意义不仅仅在于拓展知识，更多在于扩大自己的触摸空间。

分以下几个部分来分享

自动化运维的发展

这一块的内容主要来自于upyun运维总监的分享，他的讲义中讲到了他做运维的那些年踩过的坑，以及高可用的自动化运维架构。要做到部署和监控都抓好才能有更精益的性能。

精华是这张图：

可用，用好以及好用

我们目前应用层级只能做到可用和一点点用好，应用方面可以做到定时定人，但是没把自动化的运维工具用起来。监控方面zabbix目前够用，又拍运维总监讲解的时候说到zabbix到后期机器特别多的时候对服务器的内存占用较高。所以他们选择了使用ELK套件搭建监控平台，后来我网搜了一下，评价挺好的，还能够搭建日志分析平台。接下来要好好研究一下「使用ELK套件搭建日志分析平台」

项目经典架构

接下来在听唯品会架构师赵先生讲以cloud native打造大型电商系统的议题时，讲到电商系统的架构。如下图，从架构上来看，主要有四层：LB层，APP服务层(微服务)，缓存层，DB层，存在
三种典型模式：
– 主从模式
– 集群模式
– 分布式模式

Paste_Image.png

这里跟我们现在的架构也是类似的，使用了lvs分流到不同的后端服务器，使用了缓存服务和mysql。这是一个项目的经典架构也是最基础的架构，以下是一个电商系统的基础结构。

随着用户量的增长，如何能做到整个架构的稳定，赵先生这里重点讲到的就是对服务进行拆分，对DB的拆分，项目服务的拆分等等。

架构的三维图形

我们可以从X轴，Y轴，Z轴。进一步拆分。

业务的拆分

以业务为单位进行功能拆分，比如电商系统可以拆分为订单服务、用户服务、库存服务等。每个服务可以根据需要在进一步拆分为更细力度的服务。一般的大型网站可以拆分出几千个这样的服务。

DB的拆分

以mysql为例，随着访问量的上升，几乎大部分使用MySQL架构的网站在数据库上都开始出现了性能问题，web程序不再仅仅专注在功能上，同时也在追求性能。程序员们开始大量的使用缓存技术来缓解数据库的压力，优化数据库的结构和索引。开始比较流行的是通过文件缓存来缓解数据库压力，但是当访问量继续增大的时候，多台web机器通过文件缓存不能共享，大量的小文件缓存也带了了比较高的IO压力。在这个时候，Memcached/Redis就自然的成为一个非常时尚的技术产品。

主从读写分离

由于数据库的写入压力增加，缓存只能缓解数据库的读取压力。读写集中在一个数据库上让数据库不堪重负，大部分网站开始使用主从复制技术来达到读写分离，以提高读写性能和读库的可扩展性。Mysql的master-slave模式成为这个时候的网站标配了。

分表分库

随着web2.0的继续高速发展，在Memcached的高速缓存，MySQL的主从复制，读写分离的基础之上，这时MySQL主库的写压力开始出现瓶颈，而数据量的持续猛增，由于MyISAM使用表锁，在高并发下会出现严重的锁问题，大量的高并发MySQL应用开始使用InnoDB引擎代替MyISAM。同时，开始流行使用分表分库来缓解写压力和数据增长的扩展问题。这个时候，分表分库成了一个热门技术，是面试的热门问题也是业界讨论的热门技术问题。也就在这个时候，MySQL推出了还不太稳定的表分区，这也给技术实力一般的公司带来了希望。虽然MySQL推出了MySQL Cluster集群，但是由于在互联网几乎没有成功案例，性能也不能满足互联网的要求，只是在高可靠性上提供了非常大的保证。

这里又涉及到荔枝架构师讲到的，Mysql Cluster集群的CA模式：

ca模式

CAP理论

• ⼀致性(Consistency) 所有节点都能访问同⼀份最新的数据副本
• 可⽤性(Availability) 每个请求都能接收到⼀个响应，⽆论响应成功或失败，⽽不应该
  是⺴络超时、连接断开等⾮服务程序答复。
• 分区容忍性(Partition tolerance) 除了整个⺴络的故障外，其他的故障（集）都不能导致整个系统
  ⽆法正确响应。

这三个要素最多只能同时实现两点，不可能三者兼顾。

易扩展高性能且灵活的数据库

NoSQL数据库种类繁多，但是一个共同的特点都是去掉关系数据库的关系型特性。数据之间无关系，这样就非常容易扩展。也无形之间，在架构的层面上带来了可扩展的能力。NoSQL数据库都具有非常高的读写性能，尤其在大数据量下，同样表现优秀。这得益于它的无关系性，数据库的结构简单。一般MySQL使用Query Cache，每次表的更新Cache就失效，是一种大粒度的Cache，总体来说性能要高。

NoSQL无需事先为要存储的数据建立字段，随时可以存储自定义的数据格式。而在关系数据库里，增删字段是一件非常麻烦的事情。如果是非常大数据量的表，增加字段简直就是一个噩梦。这点在大数据量的web2.0时代尤其明显。NoSQL在不太影响性能的情况，就可以方便的实现高可用的架构。

MySQL和NoSQL都有各自的特点和使用的应用场景，两者的紧密结合将会给web2.0的数据库发展带来新的思路。让关系数据库关注在关系上，NoSQL关注在存储上。

分享大会中所有讲义的pdf
「云运维的启示与架构设计」
「酷狗大数据平台架构重构」
「以 Cloud Native 打造大型电商系统」
「腾讯分布式NoSQL集群运营实践」
「异地多活IDC机房架构」
「高速发展下的电商运维环境建设之路」