【CSDN在线培训QA】漫谈云上架构与运维的艺术
在7月17日“CSDN在线培训：云上架构和运维的艺术”中，UPYUN（又拍云）联合创始人兼运维总监邵海杨，为我们带来了云上运维的趋势和思考，分享了其多年来在运维方面的经验。为了帮助大家更好的复习本次培训的相关内容，CSDN整理了本次培训最后的QA如下：
Q：在做标准化时，你是怎样调和公司要求开发快点完成功能，而不能完全符合运维现有标准化这个矛盾问题的？
我们现有的标准化也是从“接盘侠”做起的，所以起初也是根据之前的遗留情况具体分析，具体应对，通过定制升级脚本（测试升级流程无问题后再批量），目的就是通过持续的改进，最终实现平台一致性。所以标准化的过程是个互相协商妥协的交流过程，操作过急并不可取，稳中求胜才是第一位。当大家磨合一段时间了，后续的项目再做标准化就非常顺利了，如果真遇到项目赶的时候，还是要遵循“先完成，再完善，后完美”的原则，只要不是严重拖延症患者，标准化并不会花费太多的时候和精力，但是换来的效益是最大的，一定要有防微杜渐的前瞻意识。
Q：运维自动化如何更好的维护? 很多时候为了快的原则，有时忽略了扩展性和重用。
使用gitlab来保存变更代码，做到追溯可寻，所有人公用一个代码仓库，保证入口准确和唯一；做到一次编写，到处运行，所以bash/sed/awk的脚本语言移植性极佳，人员互备性也好；使用文本来保存信息，可读性和移植性有保证；快可以，但要懂得何时停下来，稍作休整，把不足弥补消化，切记不要日积月累；
Q：又拍IaaS做的多吗，还是PaaS做得多？
又拍云其实做的是SaaS服务，旨在面向移动互联提供服务至上的一家集云存储，云分发，云处理一站式的云服务公司。
Q：又拍采用的是什么分布式文件系统呢？
又拍云采用的是基于Erlang并发语言，参考了Amazon的高可用Dynamo模型，使用KV模型来存储多副本数据对象，同时还提供了目录检索服务，基于RESTFul的API调用，上面还提供了有来自于官方及网友贡献的各种语言的SDK封装。
Q：又拍云存储是怎么做数据备份的？
Dynamo高可用存储模型本身就是设计成多副本存储，P2P哈希一致性，保证数据存放在不同的服务器和不同的磁盘上；机房目前采用了同城异地+裸光纤直连做灾备，多机房多数据中心已经在开发中。
Q：怎么样在不影响用户使用的情况下，动态去更新部署程序？
在线热部署热升级的秘密在于“尽量保证无单点+热加载技术”，如使用DNS轮询，LVS负载均衡，Nginx热升级，ATS cluster，Redis master/slave多级缓存。
Q：数据库的读写分离，老师有什么好的办法解决同步延迟对程序的影响，跟大家分享一下。
我不太明白你的同步延迟要求有多大，但我曾经设计过Haproxy/LVS+Mysql主从架构，用于彩票读写密集型场景，采用了Mariadb+Xtradb+SSD，性能和效果还是不错。据说最新的Mariadb底层服务框架和Xtradb/Tokudb性能都不错，可以测试一下。
Q：有没有好的办法去避免nginx的单点问题？
前面加一层负载均衡，如LVS,Haproxy，都是不错的选择。
Q：我们用淘宝的TDDL，做读写分离，TDDL的分库分表怎么做，能不能分享一下？
没有使用过，如果是自有应用，源码在自己掌握中，我还是建议从程序级别去区分读写请求，效率最高。这跟公有云开放提供给第三方开发者的数据平台是不一样的设计场景，平台的智能化是指降低开发者的门槛，所以，开发者不需要了解读写分离或分库分表的高深技巧，也能享受平台带来的可扩展性优势，但势必会带来一些解析上的开销，所以要权衡利弊。
Q：数据库读写分离有好的开源框架吗？数据库中间层处理分库分表有好的开源代码吗？
可以参考阿里的Amoeba或者 360 Atlas。
Q：我是PHP程序员，一般来说扩展的瓶颈都在数据库读取那里，不知道解决这个瓶颈常见的方法是哪些？
基于机械磁盘结构的数据库前面都要加层缓存，用于存放热数据，提供给程序调用，如memcached,redis；后端数据库最好有主从读写分离；有条件的话，可以采购一块SSD，利用flashcache/bcache技术给sata磁盘做个热区；利用慢查询工具做好查询语法的检查；如果对实时性，如事务一致性要求不苛刻，可以使用如Mongodb这样的NoSQL新型数据库；
Q：想问下比如消息队列的应用生产者和消费者如果不能很好的处理消息队列的数据的话，该如何设计才能更好的处理？
如果你已经使用了消息队列+生产者/消息者解决方案，其实整个架构已经具备了可扩展性，理论上可以通过加机器扩展消息队列集群，加机器添加生产者和消息者角色，从而线性扩展处理能力。如果研究再深入些，就是里面的数据如何压缩，如何设计成更加小巧有效，如何提升带宽吞吐率。如果压力还要再大大，就要从设计上保证消息队列也可以按业务做垂直划分。
Q：请问您对DevOps这个职业怎么看？
这是个美好的未来，我们要勇敢接受这样的挑战和变化。与其在想询问别人的看法，不如现在就行动起来，答案是肯定的。
Q：能谈谈运维和DevOps的不同，实现所谓的DevOps公司文化，运维如何更好发挥作用？
以往运维的工作就是部署环境，发布上线，监控排错以及处理各种疑难杂症，因为身处一线和最后防线，感觉总是在救火，吃力还不讨好。因此我们要转变角色，掌握主动权，如：运维自动化（开发运维平台，操作封装成web接口，实现角色分离，权限分离，操作日志记录，让开发人员也可以自主上线发布，可追溯），监控常态化（编写监控脚本，实现自动报警，自动隔离故障，为运维团队争取缓冲时间， 尽量避免限时实时处理），性能可视化（如全国地图的业务指标显示，性能展示，瓶颈点，利用这些数据可以显而易见的让每个人了解实时状态，也能提供争取资源的依据），要做好以上几点其实都离不开开发功底，同时又需要对运维的深刻理解，所以，我们要有这个理念，朝着这个方向努力做好，那我们就可以驾轻就熟的玩转运维。
Q：运维的抽象业务模型是什么，能讲个例子吗？还有就是运维的标准化组件是什么？麻烦也举个例子吧
好的，举个例子，如果我们要在nginx阻止某些恶意链接，我们只需要做二步:
1. 在/etc/upyun.cfg中填写 NGINX_BAD_SITES="bad.com"
2. /etc/init.d/nginx config;/etc/init.d/nginx reload
秘密在于config这个函数！
config(){
## block bad url
sed -r -i '/#badurl/d' $NGINX_DIR/badurl.conf
STRING=""
for i in $NGINX_BAD_URL;do
echo "$i"|grep -q "^#"
[ $? = 0 ] && continue
STRING=$STRING" location /$i/ { #badurl return 444; #badurl access_log off; #badurl } #badurl "
done
echo -e $STRING >> /tmp/.xxx
sed -r -i "/block bad url/r /tmp/.xxx" $NGINX_DIR/badurl.conf
rm -rf /tmp/.xxx
}
Q：如何在不影响业务的情况下做变革？ 怎么评价监控的尺度选取的好坏？比如选的过多，无用等。
循序渐进，掌握尺度很重要，尤其是在已经稳定运行甚至盈利的系统上，大刀阔斧的革新并不适用，建议先找出性能瓶颈点，重点突破，先赢取团队信任，然后再逐步升级改进； 坚持 “先完成，再完善，后完美”，项目也是“先能用，再好用，后用好”的实施方针，包括监控指标和运维平台亦是如此，内心不要被一些困难或者一时的挫折打败，只要坚定方向正确，实施有序，未来肯定是越来越好。
Q：如何针对多种不同服务环境的服务器进行运维？如何把这些构建在相应的平台上？
老实说，抽象业务模型需要丰富的实战经验，如果经验不足，还是要虚心多请教前辈，从前人踩过的坑里获取教训。如果你有不同的服务器环境，我建议可以用puppet/saltstack/chef等跨平台部署工具来维护，也可以关注docker这个新兴的项目，后续可以直接在统一的平台上用docker来虚拟化多平台应用，也是一种另辟蹊径的运维思路。
Q：运维自动化的脚本，是运维工程师自己编写还是什么工程师编写？
运维工程师必须要掌握bash/sed/awk三剑客编程语言，并且能够灵活应用各种linux基本命令。但是你不能止步不前，为了迎接DevOps的挑战，你还需要多掌握一门语言，我推荐是Python/Nodejs，可以一举多得，打通前后端。
Q：运维期间出现的异常故障如何与开发工程师沟通？如何为开发工程师提供故障描述？
出错日志，监控图，如果架构上没有单点故障，还可以保留现场提供调试。
Q：想问一下, 关于高并发量，怎样更好地去预防它宕机呢?
我们说在做架构的时候，除了高并发，高性能，高可扩展性，还要考虑隔离机制，就像汽车一样，有油门加速，同时也需要刹车，当遇到紧急情况，宁可慢一点也不要撑爆。如在解决在线大并发请求的时候，我们建议是松耦合，引入消息队列+任务分发框架，化并发无序的请求为有序的请求，再通过可方便水平扩展的消费者来实现并发处理。
Q：请问下，程序员出身，目前兼运维这块，入门的话，有没有推荐的好书或者一些重点，可以给个提示吗？
《鸟哥的私房菜》
Q：Node.js是单进程，单CPU的，稳定性貌似有问题，而且重重回调感觉很别扭，请问老师，Node.js最常见的应用场景是什么呢？
nodejs考虑到需要回调，因此会有一些内存持久消耗，建议用在短连接应用上，越早释放内存越好，内存占用越小越好，不适用复杂耗时的复杂逻辑查询或者IO密集型应用。如nodejs+redis/memcached/mongodb/kv搭配就比较出色，如果要做复杂查询，建议通过消息队列，或者redis这样的缓存，与后面的关系型数据库松耦合。单进程可以通过node-cluster模块获得多CPU的绑定，性能也能得到提升。
Q：Redis怎么集群化？
Redis 支持多级缓存和主从复制，我们用得最多的也就是多级缓存，基本上3～4级可以保证够用了。
Q：Python貌似在运维里出现的频率很高，在运维里常用的语言有哪些呢？
除了bash/sed/awk外，不二之选就是python,其次推荐用Node.js/Ruby
Q：技术选型确实是一个很大的问题。如何决断？考虑的因素有哪些？
话题太大，难于概全，我建议考虑的第一因素，是怎么消灭单点故障，先做到这一点，就能够让你临危不惧，争取时间，才能有精力和时间去消灭更多的性能瓶颈，慢慢完善，架构就是一个不断演变进化的过程，没必要十全十美再上线。
Q：请老师推荐一款适合大容量，高并发存储和读取的数据库工具，最好适合分布式部署，谢谢！
MongoDB吧。
Q：要搭建适合大量信号处理运算的云计算平台，从性能和功耗考虑推荐什么类型处理集群，谢谢！
用Erlang吧，天生就是并发的，尤其是在电信领域，原生支持二进制传输。
Q：有没有好的运维自动化的工具推荐？
运维自动化方面的工具有很多，puppet,chef,saltstack,ansible都是佼佼者，没有绝对好用的银弹，只有灵活应用的高手，所以，多比较再选择。比如说，你的环境中维护的服务器版本各异，跨度很大，那用ansible就比较简捷，因为它不需要安装任何agent,直接基于ssh管理。
Q：在企业环境中的私有云存储有哪些应用场景呢？采用什么接口，性能如何？有什么云安全检测工具？
无论什么样的云存储，包括私有云，公有云也好，一定要知道关注的指标是什么，如高可靠性，高可用性，高性能，高可扩展性，或者安全性。如高可靠性，就需要多副本模型，如ceph,swift等；高可用性，就要用p2p的哈希模型，如riak；高性能的，就要用KV模型；高可扩展性，也要用p2p的KV模型，最好能够提供RestFul的接口，利于水平扩展；至于云安全检测，可以寻找乌云的有偿服务，物有所值。
Q：关于服务器的CPU，内存监控，有没有较好的工具推荐，能提供性能可视化报告的？网络质量监控有没有比较好的工具？例如丢包，网络延迟。
zabbix，cacti，nmon都可以提供直观，高效率的性能监控。
Q：我只做过两台服务器的MySQL，读写分离，没做过一台的，一台读写分离有意义吗
代码级别的读写分离意义在于前瞻性和扩展性，跟后面到底是一台还是多台透明无关，我们所说的架构设计就在于细节的把握，假设你已经事先做了代码级的读写分离，也许你最初用不上，一旦业务量上来后，成败在此一举的时候，你部署好数据库主从+负载均衡，只需要改变一行代码中的一个端口，立即就能轻描淡写的化解读写压力，这才是高明之处，让人目瞪口呆，同时也让老板对你刮目相看的最佳机会。
Q：如何对运维中积极的人及消极的人进行分工？
只有能从痛苦，重复的工作中，寻找聪明的方法来突破重围，与他人协同沟通共同解决问题的人，才能真正为之着迷而坚持不懈的奋斗，才能从中得到乐趣，这也是公司希望得到的人才。所以，方法比拼命更重要，何况还不拼命，这样的人趁早劝退，免得避免整个团队的效率。建议看《极客与团队》《暗时间》。
免费订阅“CSDN云计算”微信公众号，实时掌握第一手云中消息！
CSDN作为国内最专业的云计算服务平台，提供云计算、大数据、虚拟化、数据中心、OpenStack、CloudStack、Hadoop、Spark、机器学习、智能算法等相关云计算观点，云计算技术，云计算平台，云计算实践，云计算产业资讯等服务。