Archive for the ‘架构’ Category

Codis架构笔记

Codis是起源于豌豆荚的redis Proxy项目,其主要目的是为了解决redis使用中的两个痛点:

  1. 难以动态的平行扩展增加新的redis服务.
  2. 难以运维管理.

它主要的架构是这样的:

系统扩展的三种维度

经常提到一个系统的扩展性,只谈到垂直扩展和水平扩展,其中垂直扩展是提高系统内单个系统的处理能力,比如给机器加内存,换性能更高的机器等;水平扩展通俗一点说就是加更多的机器来处理请求,而不是试图提高单机的处理能力.

<<可扩展的艺术>>一书,将一个系统的可扩展性做了更多的划分和分析,它将一个系统的扩展性划分为以下三种维度:

No Comments | Read the rest of this entry »

灰度发布系统的实现(续)

上周写完灰度发布系统相关的博文之后,有朋友表示灰度系统的实现太过简单了,因为我目前接触的系统确实比较简单,很多复杂的东西没有考虑周全,如果更大型的业务系统,涉及到的服务更多,还有如果掺杂着数据的迁移,就更复杂了.这里就把当时讨论的内容提取出来,主要的贡献者为滴滴的沈佳伟.

1.调用链上有多个业务服务的场景

考虑这样一个业务场景,假设对外提供了服务A给客户端访问,服务A后面会调用服务B,C,D,此时需要上线一个功能,这个功能涉及到了服务A,C的修改,但是服务B,D不需要变动,换言之,我们的意图是,如果一个客户端请求,走到了新的灰度服务A,那么最终这个请求也应该走到这次和A一起灰度的服务C上.

这里的处理策略,可以给客户端请求进行tag打标记的方式,比如经由新版本服务A处理的请求,全部打上tag

灰度发布系统的实现

灰度发布,已经不是一个很新的概念了.一个产品,如果需要快速迭代开发上线,又要保证质量,保证刚上线的系统,一旦出现问题那么可以很快的控制影响面,就需要设计一套灰度发布系统.

灰度发布系统的作用在于,可以根据自己的配置,来将用户的流量导到新上线的系统上,来快速验证新的功能修改,而一旦出问题,也可以马上的恢复,简单的说,就是一套A/BTest系统.

它大抵的架构,应该是类似这样的: