实录｜互联网架构“高可用”在线技术交流

原创 2016-12-06 58沈剑+GitChat 架构师之路 架构师之路架构师之路

微信号

功能介绍 架构师之路，坚持撰写接地气的架构文章

前段时间，受@谢工 邀请，在GitChat平台首发《究竟啥才是互联网架构“高可用”》。

12月01日周四晚8点30分，在微信群进行了针对该文章的的主题交流。如下是主持人@赫阳 整理的问题精华，记录下了我和读者之间关于高可用架构的问答精彩片断。

问答中全部文章都是能够直接点击跳转的哟。

 

问：在缓存层rehash过程当中必然会有脏数据。一致性hash实际上只能减小rehash的成本，不能消灭脏数据，这种脏数据有没有办法避免？

答：如文章《究竟啥才是互联网架构“高可用”》所述，若是没有高可用需求，一台 cache 挂了，不宜作rehash，会产生脏数据。此时对挂掉cache的key能够直接返回 cache miss。

问：从您后面的回答来看，这其实也是“降级”的一种，这样之后是直接把请求打到后端的数据库上么？仍是直接抛弃请求？若是发生雪崩效应，miss的请求愈来愈多，若是miss的都打库的话，库立刻就会挂了。这一块老师能再展开讲一讲么？

答：打到数据库上，cache集群的份数和数据库能抗多少读有关。理论上1-2份挂掉，数据库能抗住。58的作法，有一个 backup mc集群，有挂了能够顶上，不建议rehash。高可用的代价是冗余，冗余有成本和复杂性，一致性问题 cache 我文章中最后那种 cache 服务集群化，是比较好的方案（配上backup 集群）。

 

问：服务层到数据层，若是写是经过冗余写入保证高可用，那么根据CAP, 一致性很大可能上是不能保证的。 如何能保证基本一致性的状况的下，保证数据层的高可用？

答：根据CAP理论，通常来讲，一致性和可用性取其一，其实最终一致就行。保证了高可用，得牺牲一些一致性，以主从数据库为例，可能在主从数据同步时间窗口内，会从从库读到旧数据。

 

问：你对时间管理和自我实现有没有什么格外经验，贴以前的文章也行，想学习下。

答：时间管理我的经验，工做时关闭朋友圈、qq、各类群、邮件提醒等，它们是影响效率的主要矛盾。

自我实现？还在努力编码、写文章自我实现中。在百度的一段工做经历让我印象很深入，周围比我牛逼的同事比我努力，一直努力向他们学习。

 

问：其实第一问题个人意思是，若是不容许 cache miss 的 case 下怎么作rehash且尽量少脏数据?

答：不容许cache miss，就作cache 高可用，cache高可用也如文章，有几种实现方式。cache 一致性，见《缓存与数据库一致性保证》，这篇文章会对你有帮助。

 

问：我看了很多的大型网站的构架演进，都是从all in one而后慢慢变成服务化的系统。既然，前人开路，咱们后人已经知道最终架构，那能不能一步到达这个服务化的系统？不少人给出不能的理由是一开始就搭建这样的架构成本过高，要先发展业务再治理。可是在我看来，不少东西均可以自动化了，只要几行命令就能够把一整套基础架构搭好了，好比 jenkins 自动化集成+部署、大数据分析平台kafka+spark+zookeeper+Hadoop 等，剩下就是在在这上面写业务应用了及根据业务具体状况调参数了。正因如此，我不是很认同“成本高”这个观点。请问，到底能不能一步到达最终的服务化的系统，跳到中间的演化过程？为何？也许有人会说了，适合的架构才是好的架构，你业务量如今还达不到，就不必作成和淘宝，58的架构。我想说，若是搭建和他们相似的架构的成本很低，那我为何不搭建？简单的说，问题是：能不能跳过大多公司的架构演化过程，直接搭建最终架构？

答：架构设计多想一步，不建议想太远，若是回到10年前58同城从新创业，估计架构还会是当初那个样子，而不是如今同样。

不建议跳过演化，架构是支持业务，不一样阶段业务需求不一样，架构不一样，最好架构演化。架构师之路公众号这篇文章《好架构是进化来的》可能会对你有帮助。

 

问：服务层到数据库读的高可用与服务层到数据库写的高可用 的取舍原则应该遵循哪些方面考虑？想请沈老师的提出一下看法，看看是否给我思考的思路一致？

答：《DB主从一致性架构优化4种方法》这篇文章中有详细的介绍。

 

问：如何避免服务挂掉以后，rpc client在转移server的时候致使集群中的惊群效应？

答：个人理解，是不存在惊群的，假设原来5个服务10条链接，如今一个服务挂了，变成4个服务8条链接，只要负载分配策略是随机的，流量依然是随机的。

 

问：58到家在灰度发布和A/B是怎么样的一个落地方案？

答：灰度发布是APP的灰度发布？仍是相似推荐算法的AB测，多个算法同时运行？仍是服务的平滑升级？对于第一个，常见方法是渠道包，越狱包。对于第二个，须要有推荐算法分流平台支持。对于第三个，web/service的升级，间隔重启过程当中，要切走流量，保证全部用户不受影响。

以webserver平滑重启为例，通常从nginx层切走一天tomcat的流量，这一台升级站点重启，nginx流量再切回，这么平滑。

 

问：58是否也作了分中心的建设，中心和中心的内部调用是不是rpc这种方式，又有那些场景是用消息调用，那些用rpc服务，怎么考量的，最好有举例？

答： 58没有作多机房架构，《从IDC到云端架构迁移之路》这篇文章，讲了同城机房迁移过程当中，一段时间多机房的一些经验。原则是：不能作到彻底不跨机房，就减小跨机房，“同连”架构，具体能够看文章。

 

问: 对于内存计算怎么看，目前redis功能过低级，内存计算同时势必要读取缓存信息，是否能够在内存计算中就把缓存的事情作了，仍是缓存就是缓存，只作这一件事情？

答：不太清楚问题是想问什么，mc支持kv，redis支持一些数据结构，还有主从，还支持落地（不建议用），功能我却是以为太强大了，cache就是cache，作计算不合适，计算仍是业务服务层本身作吧。

 

问：关于缓存和数据库分布式后，从新分区后的数据迁移是否有好的方案?

答：这篇文章《58怎么玩数据库架构》讲了数据库扩容，一种秒级扩容，一种迁数据扩容（不停服务），或许有帮助。缓存的扩容，能够二倍扩容，若是像我文章中proxy+cache集群的架构，扩容其实对调用方是透明的。

 

问：你的文章介绍了每一个层级和阶段的高可用方案和设计原则，我关心的是有了这些方案和原则设计出来的东西怎么检验，设计检验方案的思路和原则？

答：不是特别理解这个“怎么检验”，高可用上线前彻底是可测的。例如nigix层高可用，作keepalived+vip后，干掉一台，测试下可否继续服务。

 

问：我想了解云环境下数据库高可用怎么作？没有vip怎么作？他们提供的负载，用起来有限制。好比mha不能作到vip漂移。

答：云端两种方式，以阿里云为例。一种ECS+自搭建DB+购买阿里云相似vip的服务，一种用直接用rds高可用数据。印象中阿里云只有主库提供rds高可用，从库貌似不高可用（须要数据库链接池本身实现）。58到家目前使用阿里云，两种方式都有用。

 

问：使用微服务的方式后如何保证某个服务的版本更新后，对其余各个服务之间的影响能尽量小？

答：和服务化粒度有关，粒度越粗越耦合，一个地方升级影响其余。粒度越细，越不影响。这篇文章《微服务架构多“微”才合适》对你或许有帮助。

 

问：架构高可用就是否架构师和运维人员的事情？开发人员有能作和须要注意的？

答：个人理解，不适合存在专职架构师负责架构设计，开发人员负责编码，自己架构就是 技术人 设计的，rd、dba、op等一块儿，高可用是你们的事情，只是说可能有个经验稍微丰富的研发（暂且叫架构师）牵头来梳理和设计。

 

问：请问老师分布式系统里面惟一全局ID的生成规则有什么好的方式么？

答：请看这篇文章《细聊分布式ID生成方法》。

 

问: 从高程转向架构师须要提升那方面的能力，在提升系统设计能力方面有什么建议？

答：这个问题有点泛，这篇文章或许有帮助（非我原创）《互联网架构师必备技能》。

 

问：假如我以前5个机器能支撑10w用户，忽然有一台机器断电了，而后流量分散到其余4台，那么这4台都超过最大值了，就会挂了，也就是惊群效应，是否作拒绝策略，具体的落地怎么去作？

答：1）若是流量能抗住，直接分配没问题。2）若是流量超出余下系统负载，要作降级，最简单的方法就是抛弃请求，只为一部分用户提供服务，而不是超出负载直接挂掉，这样全部用户都服务不了=> 服务自身须要作自我保护。

 

问：相似支付宝750积分这样的灰度，相似运营能够配置策略这种方式来控制不一样的人根据不一样的策略，接触的服务类型都是不同，这种的话具体的落地该如何去作呢？

答：这样的灰度，就是不一样的用户的界面、功能、算法都不同的，须要系统支持（开关、流量策略、分流、不一样实现），《58同城推荐系统架构设计与实现》这篇文章中“分流”的部分，应该会有帮助。

 

问：请问web集群中的数据同步，若是涉及跨机房，有什么好的方法尽可能避免跨不一样区域机房的数据同步和复制中的可靠性，或有其余更好的方法避免跨机房间的数据交互吗？

答：这是多机房的问题，后续在多机房架构的文章中在具体阐述。多机房架构常见三个方案：

1）冷备（强烈不推荐）；

2）伪多机房（跨机房读主库数据）；

3）多机房多活（入口流量切分+双机房数据同步）。

 

问：58的服务降级如何作的？

答：不说结合业务的降级（跳过非关键路径），通用的系统层面的降级，常见作法是设置队列，超出负载抛弃请求。这个方案是很差的，当一个上游请求变大，会是的全部上游排队，抛弃请求，都受影响。

58服务治理通常这么作：针对不一样调用方，限定流量；一个调用方超量，只抛弃这个调用方的请求，其余调用方不受影响。

 

===【完】===