群脉首席架构师详解SCRM架构史

由听云、极客邦和InfoQ联合主办的中国应用性能管理行业盛宴——2016中国应用性能管理大会（简称APMCon 2016）在北京新云南皇冠假日酒店隆重召开。作为国内APM领域最具影响力的技术大会，首次举办的APMCon以“驱动应用架构优化与创新”为主题，致力于推动APM在国内的成长与发展。
　　群脉SCRM首席架构师 房玉峰基于云架构的性能深度优化实例，现场分享了群脉和云服务的成长之路 ，这对于正在利用云服务快速迭代和发展的团队而言具有深刻的借鉴意义。

　　群脉SCRM首席架构师房玉峰
　　本文根据8月18号和19号在北京举办的 2016中国应用性能管理大会 的演讲PPT整理而来。
　　三年的过程，国内的云服务从无到有，从功能单一、能力薄弱到提供的服务越来越丰富、性能越来越强；在这三年里，我们的产品也从无到有，从简单架构到架构越来越复杂，我们都站在云的肩膀之上借云之力快速演进。
　　今天借这个机会，和大家分享近三年群脉产品的演进之路，我们的产品从无到有的构建过程中遇到的问题，以及我们是如何利用云服务来快速的解决我们的问题的一些想法和思路。[如果想更多的了解产品，请移步 www.maiscrm.com 或者搜索 群脉 SCRM]
　　产品架构的三次演变
　　群脉到目前为止经历了两次大的架构调整。
　　1.0 的架构，我们的目的性很强：活下来，期间我们经历了开始从自建机房到采用云服务的思路转变。这一路我们快速的发展，开始有很多的大品牌客户选择我们的产品，我们进入一个快速演进的 2.0 阶段。在这个阶段，很自然的我们遇到了各种问题，有研发流程方面也有架构方面的问题。面对这些问题，我们会优先选择直接利用现有的云服务、SaaS服务和工具，简单、“粗暴”地解决。占在云和SaaS服务的肩膀上，可能现在的方案只能解决我们80%的问题，但是考虑到时间成本和人力成本，我们还是认为这是一个正确的选择。
　　1.0 和 2.0 的架构，说白了我们其实都还是在做 1+1 = 2 的事情，而我们正在演化中的架构 3.0，其实我们想做的是一些 1+1 > 2 的事情，后面会分享一下我们的思路和想法。
　　产品架构 1.0
　　1.0 架构的一个很大的特点，就是团队开始了从自建机房到采用云服务的一个转变。当然这背后有很多很现实的问题。
　　第一现实的问题，便是团队缺乏构建机房的经验。在构建群脉这个自研的产品之前，我们的团队已经在互联网产品的研发上耕耘了很多年，但是我们承担的角色更多的还是停留在研发上。不管是08年的奥运网络直播，还是09年作为央视的合作伙伴承建国家网络电视台的西柚视频平台，还是10年协助SMG自建机房、打造新一代的第一财经网站，我们提供的服务模式都是：我们帮客户把软件架构做好、研发完成，然后客户的运维团队，针对我们的要求采购服务器，搭建机房和硬件设施，最后我们把研发的产品部署到客户准备的机房服务器上。
　　可以说，团队懂得如何快速的把软件做出来，但是并没有实际的经验去构建机房和持续的运维。 –这是团队的现状。
　　第二比较现实的问题，就是时间成本。如果你的团队不缺人，当然一开始就可以并行的准备一个初具规模的运维团队，但是，团队尤其是起步的初创团队，人员是最缺的，所以这样一个小团队，只能集中核心力量，优先解决最核心的产品需求，最短最快的时间内，把产品做出来，验证产品存活的可行性。 –这是团队面对的需求现状。
　　第三个因素，刚好，那时、那点，云在中国开始起步。

　　与其说是，“天时地利人和”，不如说是被逼的走上云的不归路。
　　1.0 的时候，面对刚刚起步的云服务，我们更多的是把它们当成“云主机”来看待，而在那个时候，云上也只有云主机这种单一的服务类型，甚至连负载均衡都没有，我们需要购买比较大的带宽，自建负载均衡。

　　所有网站服务和API服务都无状态化，自建负载均衡：
基于DNSPod的DNS轮询
购买ECS自建Nginx的反向代理
ECS靠水平扩展和垂直升级；DB服务器纯靠不断的升级配置来解决不断增加的流量
　　数月之后，阿里云做了第一个大版本的升级，这个时候终于有了负载均衡SLB，我们也快速跟进，把ECS的带宽降到1M，把自建的负载均衡切回了SLB：

　　1.0的架构，可以说我们在：快开发、慢运维，寻找满足团队80%需求的折中点！为了快，我们在做技术选型和云服务选型的时候会坚持8-2原则，即，如果一个现有的云服务或者SaaS服务，已经能满足我80%的需求了，我们就放弃自建而采用。例如，当时SLB并不支持SSL，我们会退而求其次用TCP转发代替https的SLB，SLB也不支持按照HTTP Path将请求转发到后端不同的服务器上，我们就将路由规则全部用域名来代替；再比如云上没有NAS，我们会选择加一点开发力量，把存储切换到七牛，同时利用七牛便利的图片处理能力来替换我们的图片裁剪和托管。在这个过程中，我们也重视“慢”运维，所谓慢，其实是我们也在慢慢的构建自己的运维团队，开始做全面的运维监控以及自动化的事情，但是我们做到工具“刚刚好”满足我们的需求即可。
　　1.0 的架构，虽然我们在云上也是刚刚起步，但是我们也还是遇到了很多的问题，有一些相信对于现在的初创团队也会有所帮助：
SLB的健康检查很重要，一定要开，不然后端的服务器出了故障无法自动摘除。但是，但是，一定要注意频率！而且，记住一定要把健康检查的access log关闭，不然可能不经意间磁盘就被access log吃光了。
阿里云上的云盾，不是万能的，不要以为有了云盾就万事大吉。该关闭的端口一定要关闭，同时一定要开启安全报警。我能不告诉你由于我们不重视有十几台ECS被作了肉鸡的惨痛教训吗… 除了云盾，用好安全组，用好安全组，用好安全组。之前有一篇介绍安全组的文章可以参考：云思路 | 云服务的安全（1）网络安全组

　　呼之欲出的架构 2.0
　　1.0 的架构有很多的问题，其中最大的问题就是缺乏架构，或者说是没有架构，然后突然有一天，你发现团队的开发速度慢了下来，开始出现各种坏味道的苗头和代码的“臭味”：
大面积的代码冗余，A客户和B客户都需要的功能但是偏偏有10%的差异，由于采用了复制、小修小改而挖下了坑，后期维护成本越来越高
数据冗余严重，因为冗余而造成的数据不一致的bug频频出现
代码里到处充斥的“小”架构，为了解决一些复制粘贴的问题，为了解决if/else的问题，四处约定了不同的规范和方案，而且比较零散
　　这个时候，云在国内开始呈现一片欣欣向荣的局面：
云服务的种类更多，除了ECS，还出现了云数据库，常用的RDS和缓存DB；出现了日志服务，大数据服务；甚至有了各种便于集成的互联网中间件等。
面向开发者发声的SaaS工具也一片大好：短信有云片SaaS服务，邮件有SendCloud服务，CDN和存储有七牛、阿里云等等。这些服务在各个领域提供优质的提高开发效率的利器（想想当年发短信我们可以买短信猫，发邮件要和邮件厂商对接一两个星期）。
　　我们的研发团队规模也在这个时候有了一个巨大的扩容：
由于客户增多同时我们针对大客户提供专属的私人定制的服务，我们的团队结构开始做一些调整，同时有标准产品团队来解决通用的产品需求，以及定制团队来服务不同行业的大客户，团队迅速扩大到100+。

　　究其各种原因，我们急需要针对1.0的架构进行调整和升级，来解决我们在团队结构和系统层面的问题。
　　产品架构 2.0
　　2.0 “架构” 来解决人员和团队层面的问题
　　为了便于多个团队高效的配合，我们需要有一种机制，来让多个团队基于同一套产品架构并行的开发和演进。为此我们借鉴了 Wordpress 的插件机制，在基于Yii2框架之上，构建了模块系统。不同的团队，只要基于我们的模块规范，按照约定的配置和命名约定添加模块的代码，再通过git submodule的方式链接进来，我们的构建系统就会在部署的时候分别针对前端代码和后端代码进行“编译”和“连接”，然后完成统一的发布。同时，通过管理平台让不同的客户可以看到不同的模块。
　　这样一点简单的改进，团队基于规范和约定，辅以自动化的构建工具，完成了互不干扰的并行开发。
　　2.0 “架构” 来解决系统层面的问题
　　系统层面我们第一需要解决的就是模块通信的问题，为此我们引入了消息中间件服务，基于阿里云的消息队列构建而来；其次面对生产环境的问题，我们急需要快速的找到线上问题的根源并提供解决方案，我们基于SLS日志服务，快速构建了API的慢响应报表系统以及错误日志追踪系统。
　　站在巨人肩膀上的 2.0 架构原型

　　2.0 的架构我想和大家分享的重点是，云让创业团队和大厂有机会重新站在同一个起跑线上！
真正的不用再关心基建
创业团队可以方便的享用大厂在高并发、高性能、大数据等领域的积累
　　两个小故事，和大家分享一下我们虽然做了2.0大的架构调整，但是因为集成了云服务，我们的调整速度非常快。
　　第一个就是消息队列的架构调整。我们当初调研了Kafka，还对Kafka做了蛮多的测试，但是当我们去调研，云上是否有Kafka的服务的时候，我们发现国内除了青云，并没有提供直接可用的Kafka服务的云服务厂商，由于我们的服务构建在阿里云之上，所以我们就在想，是否可以转换一下思路，看看阿里云上有没有现成可用的消息队列？结果我们发现SLS配合Log Hub可以替换Kafka，阿里云也有消息服务也有消息队列服务，我们还和阿里云的团队沟通了很久，包括直接和他们的工程师对话，针对我们的场景到底应该用哪个服务更便捷。最后，我们选定了消息队列，第一它是淘宝和双11的基础服务，第二，它有开源的版本RocketMQ，我们在本地自建也方便测试。这个架构的调整，我们只做了两周就快速的完成，主要的原因就是因为0运维，加上云上服务丰富的集成SDK。不可想像如果我们选用Kafka的话，再Kafka高可用和高性能上，要花去多少的研发时间成本。
　　第二个故事就是我提到的关于API统计报表和线上错误日志。我们做技术和方案选型的时候，知道有一些优秀的开源方案，例如ELK，但是要采购机器、构建自动化部署、以及持续的运维。我们就想着，是否可以利用云上现成的一些服务，快速的构建一个满足我们需求的产品。结果，我们利用： Nginx打印响应日志到access log，利用Logtail将access log同步到SLS，再通过SLS的自动同步功能把结构化的数据同步到ODPS，然后我们丢一个Jar上去基于ODPS快速的做API的统计报表和慢响应报表。基于这个思路，我们差不多用了不到2周的时间就完成了一个API统计系统、慢请求报表系统，以及错误日志追踪系统。
　　架构 2.0 我们也踩过一些坑，一些经验和大家分享
在做微信整合的过程中，最好在前期就考虑到它的API rate limit限制，以及，它的IP白名单是有20个限制了，不然等你机器快速加到20台的时候，想加服务器也加不了，哭爹叫娘也晚了（通宵改架构的都是泪）
重视你的API和服务的自动化测试，自动化测试，自动化测试
调用任何第三方的服务，都要加超时时间，都要加超时时间，都要加超时间（被阿里云的Redis偶尔一次的慢响应拖垮系统的，又都是慢慢的泪无处诉啊）
和钱有关的活动，要防羊毛党，要防羊毛党，要防羊毛党！推荐阿里云的数据风控服务。当然，你也可以快速低成本的基于SLS+ODPS来实现一套。
　　2.0 的架构，美中不足的技术债还是很多
　　折中是把双刃剑，它能快速的解决问题，例如：
新加了搜索条件，对应的加个索引解决问题，实现也快、搜索也快
统计数据有时候会丢失，但是又不频繁，直接集成一下短信提醒，统计报错了发条短信给负责人，在客户发现之前手动数据找回
　　但是，折中在长期会欠债太多，就需要新的架构调整来彻底解决一系列的问题：
索引有一天实在多到连开发都觉得再加索引都不忍心了；这个时候我们快速的把搜索系统构建上来，把关键数据同步到阿里云的OpenSearch，一个人做三周彻底搞定未来很长一段时间也不用担心搜索的问题
客户多了，统计越来越慢报警越来越多，救火已经占了开发太多的时间；用ODPS重写统计服务，小数据有时候也可以“杀猪用牛刀”
　　同时，2.0时候的模块系统开始慢慢暴露出更多的问题：
由于没有做DB隔离，开始出现更多的数据不一致甚至出现了数据丢失但是不知道是被哪个模块的代码干掉的问题
自动化构建和部署的时间越来越长，停机的时间越来越久
　　3.0 呼之欲出

利用微服务，替换现有的模块机制，来完成模块的数据隔离、服务隔离，以及模块服务的自治
全线Docker化，基于docker image的自动化部署替换当前的部署方式
　　目前正在进行中的3.0改造，我们的思路还是会“站在巨人的肩膀上”，用最快最直接有效的方案解决我们问题。如果变化来的很容易，也许，你的团队也就不惧怕变化！