笔者按：作为开心保系统架构不断演化的主要参与者和见证者，6年来的踩的雷，埋得坑已经无法统计，我想这也是每一个稍有规模的网站的必经之路，这个世界只有遇不到的问题，没有解决不了的问题，高手之所成为高手，是因为他们遇到了常人很难遇到的问题并解决了。所以百度有最多广告搜索的高手，淘宝有很多海量数据的高手，QQ有很多高并发业务的高手，原因大抵如此。一个100万用户的网站，不会遇到1亿用户同时在线的问题；一个拥有100万件商品网站的工程师，可能无法理解一个拥有10亿件商品网站的架构。虽然开心保的流量和业务规模还远没有达到bat的量级，但是有些通用的东西和显而易见的道理却是放之四海而皆准的。我一直受益于互联网的分享精神，并时时告诫和督促自己不要只是索取，而我分享的东西是所有网站都可能遇到的，没有什么秘密可言，同时也断定不会对公司带来不好的影响。回首来时的路，那条足迹已经变得模糊，而留住这一切的唯一方式就是记下来，并据此更好的展望未来。
网站的架构和公司的业务规模是相辅相成的，在业务规模几乎可以忽略不计的时候没必要把架构设计的太完美，成本大不说，资源浪费太严重，架构的优势只有在业务发展的不同阶段才能够凸显出来，所以开心保在网站刚刚上线的时候只有一台服务器，并且也没有任何的安全防护措施，基本就是在互联网上裸奔，印象最深的是曾经一个月内被肉鸡了3次，想想那时候，天天查肉鸡，逛肉鸡市场，分析肉鸡的特征，白手起家的艰辛就不说了，最终liunx服务器内核的优化和安全设置方面的知识就这样在实践中有了长进，所以驱动很重要！
单点故障是只有一台服务器最致命的伤，无论流量多小，避免单点故障应该是最低要求的配置了，所以不久以后就搞了两台服务器做负载均衡和失效转移，同时把nginx也分离出来单独部署，并使用其负载均衡的模块进行集群调度，nginx的负载均衡机制在无状态的情况下效果显著，但是对于有状态时的请求却问题多多，经常会出现用户前一分钟还在登录中，但是一刷新页面却是未登录状态，服务器的连接无法保持，在没有使用session共享的情况下通过cookie跟踪确保了用户的请求一直保持在一台机器上，但是这种方法的弊端也显而易见，最后抛弃了用nginx进行负载均衡的方式，采用阿里云的SLB产品来替代，只是使用nginx进行反向代理了。
说实话，一开始阿里云的SLB产品真的很坑爹，说我们是看着它一点点成长完善起来的一点也不过分。那时候的阿里云还像一个襁褓中的婴儿嗷嗷待脯，脆弱的令人心惊肉跳，要不是一开始用的万网的虚拟主机，而阿里云又把万网收购了，最后使用的不一定就是阿里云了，但是，话又说回来，阿里云还算很给力的，这几年的发展势头迅猛，把腾讯云，百度云远远的甩在了后面，产品线相当丰富，确实给中小企业带来了极大的便利。言归正传，那时候使用SLB还属于公测阶段，记得过了很长时间才商用，可想而知，那时候的用户其实就是小白鼠，问题五花八门，我印象最深的也是会话无法保持的问题，通过sessionid无法使会话一直连接到一台机器上，当时和阿里云的技术人员频繁沟通，一起查问题，反复测试，但还是放弃了一段时间，重新启用了nginx的负载均衡模块，通过自己的摸索也解决了会话无法保持的问题。只是后来听说SLB稳定以后又切换了回来。单点故障的隐患消除了，这种架构至少可以在网站可用性上有了一定的保证。
安全问题起初是开心保的主要忧虑，因为我们没有专门的安全工程师，甚至连专门的服务器管理员都没有，遇到攻击只能根据日志，边学边写脚本分析攻击特征，发现来源了就用最笨的方法加入到黑名单，效率低不说效果也不明显，再加上处于网站建设的初期，针对开发没有任何的安全开发规范，导致应用本身有很多的漏洞，这些漏洞轻易就会被黑客利用，服务器的权限极易被获取，从而沦为肉鸡，我是深受其苦，当时我能想到的就是使用nginx的黑名单机制和linux系统的防火墙策略来抵御攻击，由于攻击太过猖獗，始终不能控制在可接受的水平，经常服务器的资源就被无缘无故的用尽而导致正常用户对网站的访问受阻，好在那时的流量小，影响也不大，可以有较多的时间进行自我知识更新和实验。加上了云盾后，在一定程度上缓解了攻击。这个时期网站的访问量虽说也不大但是相对于刚起步时翻了很多倍了，由于服务器的起始配置比较低，当时有两种方案可以解决资源不足的问题，一时提升单机的资源配置，比如增加CPU的核数，提升内存的值，二是把应用分开部署，降低单机压力。从长远考虑，应用分开部署可以有更清晰的边界，互相之间的影响也最小从而降低了应用直接的耦合，所以采用了第二种方案，增加了两台服务器用于部署分离出来的产品中心和经代通，同时把数据库也独立了出来，这样一个中小型规模的网站架构就具备了雏形，为以后的进一步扩展创造了条件。
网站的可用性得到有了一定保证以后，如何提升用户体验是所有网站管理者面临的课题，访问网站是用户最直接的感受就是访问速度了。当然，网站的访问速度的影响要素有很多，前端页面的渲染、文件的加载，压缩，逻辑的优化以及数据库查询效率的提升等等，如果把每次请求都传递到逻辑服务器甚至数据库，就会导致服务器或数据库的压力大增，待达到一定的阈值，超过了服务器资源利用率的临界点，服务器就会崩溃，网站就会逐渐变慢进而不可访问，而这是所有硬件最终都会面临的瓶颈。固然可以通过增加服务器的数量来缓解，但这不是唯一的方法，而解决这一问题公认的效果最好，成本最低的手段就是使用缓存，CDN是把静态资源缓存到运营商一端，用户访问时的大部分请求可以由运营商的缓存服务器节点响应，这样真正到达应用服务器和数据库的请求量就会大大降低，从而减轻其压力，同时由于用户访问时的大部分请求都是由离用户最近的节点响应的，所以在速度上大大提升，体验也更好，这种机制就是CDN。
CDN缓存的理论上只是静态资源，但对动态资源也有影响，如果静态资源的访问路径和主域名用的一样，那么由通过DNS解析到CName的CDN缓存机制决定的，势必会影响到全站，这就会导致很多无法预知的问题，所以如果要使用CDN，首先要把动静态资源进行分离，这种分离除了在访问域名上进行分离，在物理地址的部署上最好也分离，下面架构中增加的服务器就是专门存放js,css,jpg,png,gif等静态资源的，而这些静态资源使用专属的域名，并对其进行单独的cdn加速，这样不但对动态资源没有任何影响，同时在请求网页的时候，多个域名并行加载，也在一定程度上提升了访问速度，针对不经常变动的资源就可以把缓存时间定的长一些以确保体验的连续性，不过CDN带来的一个不足的地方就是有资源更新的时候需要手动刷新缓存，其实这可以通过增加版本号来解决。
随着平台的增多，数据库无论从数据结构上还是数据量上都变得有些臃肿，这个阶段分库就变得很与必要了，我们的这个分库只是从业务的角度进行了切分，并不是技术层面的，未来从技术层面进行横向分库和纵向的切片是必须而且一定要去做的。
这个阶段我们其中的一个渠道的日PV已经达到了5-6万，品牌的知名度也有了很大的提升，前期的SEO建设的效果开始显现，合作渠道也明显增加，系统具备了一个中等规模网站的一些主要特征，流量，转化率以及销售规模等各项指标均大幅增长，从前面几个阶段系统演化的路径可以看出，在扩展性、伸缩性做的一些工作都是从长远的角度考虑的，可以随时根据业务需要进行服务器的增减，确保可用性是所有电子商务网站运营的最基本要求，有时甚至需要牺牲次要功能的可用性来确保主要功能的稳定可用，这也是有所取舍的哲学思想的体现，系统如人生。短信、邮件，数据采集，应用监控等外围支持的功能和平台也陆续到位，基本形成了比较完整的网站架构，完成了支撑业务体系的系统建设的初期目标。
下图是开心保网站最新的业务系统架构，引进了当下比较流行的Redis缓存，Active消息队列，Dubbo服务框架，Zookeeper分布式应用程序协调服务，为下一步增加分布式系统基因做准备，同时在核心功能上做了模块化的切分，针对共通的功能封装成了接口，大大降低了系统间的耦合度，同时减少了冗余，增加了代码复用性，提供了开发效率。系统监控的力度也增强了，无论是服务器的cpu，内存，磁盘使用率，进程数以及带宽的使用情况，还是上百个服务的任何一个出现访问异常都会第一时间通报给相关人员，确保第一时间恢复，所有这一切都是确保对可用性的影响降到最低。
无论是系统架构还是应用架构，架构的优化永远没有终点，每个公司都有其演化的过程，架构的重要性不言而喻，架构师的最大价值不在于掌握多少先进的技术，而在于具有将一个大系统切分成N个低耦合的子模块的能力，这些子模块包含横向的业务模块，也包含纵向的基础技术模块。这种能力一部分源自专业的技术和经验，还有一部分源自架构师对业务场景的理解、对人性的把握，甚至对世界的认知。
评论