GOWEB常见大型Web项目分层，灰度发布和ABtest

　　流行的Web框架大多数是MVC框架，MVC这个概念最早由Trygve Reenskaug在1978年提出，为了能够对GUI类型的应用进行方便扩展，将程序划分为：  控制器（Controller）- 负责转发请求，对请求进行处理。  视图（View） - 界面设计人员进行图形界面设计。  模型（Model） - 程序员编写程序应有的功能（实现算法等等）、数据库专家进行数据管理和数据库设计（可以实现具体的功能）。
　　随着时代的发展，前端也变成了越来越复杂的工程，为了更好地工程化，现在更为流行的一般是前后分离的架构。可以认为前后分离是把V层从MVC中抽离单独成为项目。这样一个后端项目一般就只剩下 M和C层了。前后端之间通过ajax来交互，有时候要解决跨域的问题，但也已经有了较为成熟的方案。
　　前后分离交互图
　　图里的Vue和React是现在前端界比较流行的两个框架，因为我们的重点不在这里，所以前端项目内的组织我们就不强调了。事实上，即使是简单的项目，业界也并没有完全遵守MVC框架提出者对于M和C所定义的分工。有很多公司的项目会在Controller层塞入大量的逻辑，在Model层就只管理数据的存储。这往往来源于对于model层字面含义的某种擅自引申理解。认为字面意思，这一层就是处理某种建模，而模型是什么？就是数据呗！
　　这种理解显然是有问题的，业务流程也算是一种＂模型＂，是对真实世界用户行为或者既有流程的一种建模，并非只有按格式组织的数据才能叫模型。不过按照MVC的创始人的想法，我们如果把和数据打交道的代码还有业务流程全部塞进MVC里的M层的话，这个M层又会显得有些过于臃肿。对于复杂的项目，一个C和一个M层显然是不够用的，现在比较流行的纯后端API模块一般采用下述划分方法：  Controller，与上述类似，服务入口，负责处理路由，参数校验，请求转发。  Logic/Service，逻辑（服务）层，一般是业务逻辑的入口，可以认为从这里开始，所有的请求参数一定是合法的。业务逻辑和业务流程也都在这一层中。常见的设计中会将该层称为 Business Rules。  DAO/Repository，这一层主要负责和数据、存储打交道。将下层存储以更简单的函数、接口形式暴露给 Logic 层来使用。负责数据的持久化工作。
　　每一层都会做好自己的工作，然后用请求当前的上下文构造下一层工作所需要的结构体或其它类型参数，然后调用下一层的函数。在工作完成之后，再把处理结果一层层地传出到入口。
　　请求处理流程
　　划分为CLD三层之后，在C层之前我们可能还需要同时支持多种协议。本章前面讲到的thrift、gRPC和http并不是一定只选择其中一种，有时我们需要支持其中的两种，比如同一个接口，我们既需要效率较高的thrift，也需要方便debug的http入口。即除了CLD之外，还需要一个单独的protocol层，负责处理各种交互协议的细节。这样请求的流程就会变成下图所示。
　　这样我们Controller中的入口函数就变成了下面这样：  func CreateOrder(ctx context.Context, req *CreateOrderStruct) (     *CreateOrderRespStruct, error, ) {     // ... }
　　CreateOrder有两个参数，ctx用来传入trace_id一类的需要串联请求的全局参数，req里存储了我们创建订单所需要的所有输入信息。返回结果是一个相应结构的错误。可以认为，我们的代码运行到Controller层之后，就没有任何与＂协议＂相关的代码了。在这里你找不到 http.Request  ，也找不到 http.ResponseWriter  ，也找不到任何与thrift或者gRPC相关的字眼。
　　在协议(Protocol)层，处理http协议的大概代码如下：  // defined in protocol layer type CreateOrderRequest struct {     OrderID int64 `json:＂order_id＂`     // ... }  // defined in controller type CreateOrderParams struct {     OrderID int64 }  func HTTPCreateOrderHandler(wr http.ResponseWriter, r *http.Request) {     var req CreateOrderRequest     var params CreateOrderParams     ctx := context.TODO()     // bind data to req     bind(r, &req)     // map protocol binded to protocol-independent     map(req, params)     logicResp,err := controller.CreateOrder(ctx, ¶ms)     if err != nil {}     // ... }
　　理论上我们可以用同一个请求结构体组合上不同的tag，来达到一个结构体来给不同的协议复用的目的。不过遗憾的是在thrift中，请求结构体也是通过IDL生成的，其内容在自动生成的ttypes.go文件中，我们还是需要在thrift的入口将这个自动生成的结构体映射到我们logic入口所需要的结构体上。gRPC也是类似。这部分代码还是需要的。
　　聪明的读者可能已经可以看出来了，协议细节处理这一层有大量重复劳动，每一个接口在协议这一层的处理，无非是把数据从协议特定的结构体(例如 http.Request  ，thrift的被包装过了) 读出来，再绑定到我们协议无关的结构体上，再把这个结构体映射到Controller入口的结构体上，这些代码长得都差不多。差不多的代码都遵循着某种模式，那么我们可以对这些模式进行简单的抽象，用代码生成的方式，把繁复的协议处理代码从工作内容中抽离出去。
　　先来看看HTTP对应的结构体、thrift对应的结构体和我们协议无关的结构体分别长什么样子：  // http 请求结构体 type CreateOrder struct {     OrderID   int64  `json:＂order_id＂ validate:＂required＂`     UserID    int64  `json:＂user_id＂ validate:＂required＂`     ProductID int    `json:＂prod_id＂ validate:＂required＂`     Addr      string `json:＂addr＂ validate:＂required＂` }  // thrift 请求结构体 type FeatureSetParams struct {     DriverID  int64  `thrift:＂driverID,1,required＂`     OrderID   int64  `thrift:＂OrderID,2,required＂`     UserID    int64  `thrift:＂UserID,3,required＂`     ProductID int    `thrift:＂ProductID,4,required＂`     Addr      string `thrift:＂Addr,5,required＂` }  // controller input struct type CreateOrderParams struct {     OrderID int64     UserID int64     ProductID int     Addr string }
　　我们需要通过一个源结构体来生成我们需要的HTTP和thrift入口代码。再观察一下上面定义的三种结构体，我们只要能用一个结构体生成thrift的IDL，以及HTTP服务的＂IDL（只要能包含json或form相关tag的结构体定义信息）＂ 就可以了。这个初始的结构体我们可以把结构体上的HTTP的tag和thrift的tag揉在一起：  type FeatureSetParams struct {     DriverID  int64  `thrift:＂driverID,1,required＂ json:＂driver_id＂`     OrderID   int64  `thrift:＂OrderID,2,required＂ json:＂order_id＂`     UserID    int64  `thrift:＂UserID,3,required＂ json:＂user_id＂`     ProductID int    `thrift:＂ProductID,4,required＂ json:＂prod_id＂`     Addr      string `thrift:＂Addr,5,required＂ json:＂addr＂` }
　　然后通过代码生成把thrift的IDL和HTTP的请求结构体都生成出来，如  图 5-16所示
　　至于用什么手段来生成，你可以通过Go语言内置的Parser读取文本文件中的Go源代码，然后根据AST来生成目标代码，也可以简单地把这个源结构体和Generator的代码放在一起编译，让结构体作为Generator的输入参数（这样会更简单一些），都是可以的。
　　当然这种思路并不是唯一选择，我们还可以通过解析thrift的IDL，生成一套HTTP接口的结构体。如果你选择这么做，那整个流程就变成了  图 5-17  所示。
　　看起来比之前的图顺畅一点，不过如果你选择了这么做，你需要自行对thrift的IDL进行解析，也就是相当于可能要手写一个thrift的IDL的Parser，虽然现在有Antlr或者peg能帮你简化这些Parser的书写工作，但在＂解析＂的这一步我们不希望引入太多的工作量，所以量力而行即可。
　　既然工作流程已经成型，我们可以琢磨一下怎么让整个流程对用户更加友好。
　　比如在前面的生成环境引入Web页面，只要让用户点点鼠标就能生成SDK，这些就靠读者自己去探索了。
　　虽然我们成功地使自己的项目在入口支持了多种交互协议，但是还有一些问题没有解决。本节中所叙述的分层没有将中间件作为项目的分层考虑进去。如果我们考虑中间件的话，请求的流程是什么样的？
　　之前我们学习的中间件是和HTTP协议强相关的，遗憾的是在thrift中看起来没有和HTTP中对等的解决这些非功能性逻辑代码重复问题的中间件。所以我们在图上写 thrift stuff  。这些 stuff  可能需要你手写去实现，然后每次增加一个新的thrift接口，就需要去写一遍这些非功能性代码。  灰度发布和 A/B test
　　中型的互联网公司往往有着以百万计的用户，而大型互联网公司的系统则可能要服务千万级甚至亿级的用户需求。大型系统的请求流入往往是源源不断的，任何风吹草动，都一定会有最终用户感受得到。例如你的系统在上线途中会拒绝一些上游过来的请求，而这时候依赖你的系统没有做任何容错，那么这个错误就会一直向上抛出，直到触达最终用户。形成一次对用户切切实实的伤害。这种伤害可能是在用户的APP上弹出一个让用户摸不着头脑的诡异字符串，用户只要刷新一下页面就可以忘记这件事。但也可能会让正在心急如焚地和几万竞争对手同时抢夺秒杀商品的用户，因为代码上的小问题，丧失掉了先发优势，与自己蹲了几个月的心仪产品失之交臂。对用户的伤害有多大，取决于你的系统对于你的用户来说有多重要。
　　不管怎么说，在大型系统中容错是重要的，能够让系统按百分比，分批次到达最终用户，也是很重要的。虽然当今的互联网公司系统，名义上会说自己上线前都经过了充分慎重严格的测试，但就算它们真的做到了，代码的bug总是在所难免的。即使代码没有bug，分布式服务之间的协作也是可能出现＂逻辑＂上的技术问题的。
　　这时候，灰度发布就显得非常重要了，灰度发布也称为金丝雀发布，传说17世纪的英国矿井工人发现金丝雀对瓦斯气体非常敏感，瓦斯达到一定浓度时，金丝雀即会死亡，但金丝雀的致死量瓦斯对人并不致死，因此金丝雀被用来当成他们的瓦斯检测工具。互联网系统的灰度发布一般通过两种方式实现：  通过分批次部署实现灰度发布  通过业务规则进行灰度发布
　　在对系统的旧功能进行升级迭代时，第一种方式用得比较多。新功能上线时，第二种方式用得比较多。当然，对比较重要的老功能进行较大幅度的修改时，一般也会选择按业务规则来进行发布，因为直接全量开放给所有用户的风险实在太大。  通过分批次部署实现灰度发布
　　假如服务部署在15个实例（可能是物理机，也可能是容器）上，我们把这15个实例分为四组，按照先后顺序，分别有1-2-4-8台机器，保证每次扩展时大概都是二倍的关系。
　　为什么要用2倍？这样能够保证我们不管有多少台机器，都不会把组划分得太多。例如1024台机器，也就只需要1-2-4-8-16-32-64-128-256-512部署十次就可以全部部署完毕。
　　这样我们上线最开始影响到的用户在整体用户中占的比例也不大，比如1000台机器的服务，我们上线后如果出现问题，也只影响1/1000的用户。如果10组完全平均分，那一上线立刻就会影响1/10的用户，1/10的业务出问题，那可能对于公司来说就已经是一场不可挽回的事故了。
　　在上线时，最有效的观察手法是查看程序的错误日志，如果较明显的逻辑错误，一般错误日志的滚动速度都会有肉眼可见的增加。这些错误也可以通过metrics一类的系统上报给公司内的监控系统，所以在上线过程中，也可以通过观察监控曲线，来判断是否有异常发生。
　　如果有异常情况，首先要做的自然就是回滚了。  通过业务规则进行灰度发布
　　常见的灰度策略有多种，较为简单的需求，例如我们的策略是要按照千分比来发布，那么我们可以用用户id、手机号、用户设备信息，等等，来生成一个简单的哈希值，然后再求模，用伪代码表示一下：  // pass 3/1000 func passed() bool {     key := hashFunctions(userID) % 1000     if key <= 2 {         return true     }      return false } 可选规则
　　常见的灰度发布系统会有下列规则提供选择：  按城市发布  按概率发布  按百分比发布  按白名单发布  按业务线发布  按UA发布(APP、Web、PC)  按分发渠道发布
　　因为和公司的业务相关，所以城市、业务线、UA、分发渠道这些都可能会被直接编码在系统里，不过功能其实大同小异。
　　按白名单发布比较简单，功能上线时，可能我们希望只有公司内部的员工和测试人员可以访问到新功能，会直接把账号、邮箱写入到白名单，拒绝其它任何账号的访问。
　　按概率发布则是指实现一个简单的函数：  func isTrue() bool {     return true/false according to the rate provided by user }
　　其可以按照用户指定的概率返回 true  或者 false  ，当然， true  的概率加 false  的概率应该是100%。这个函数不需要任何输入。
　　按百分比发布，是指实现下面这样的函数：  func isTrue(phone string) bool {     if hash of phone matches {         return true     }      return false }
　　这种情况可以按照指定的百分比，返回对应的 true  和 false  ，和上面的单纯按照概率的区别是这里我们需要调用方提供给我们一个输入参数，我们以该输入参数作为源来计算哈希，并以哈希后的结果来求模，并返回结果。这样可以保证同一个用户的返回结果多次调用是一致的，在下面这种场景下，必须使用这种结果可预期的灰度算法。
　　先set然后马上get
　　如果采用随机策略，可能会出现像这样的问题：
　　举个具体的例子，网站的注册环节，可能有两套API，按照用户ID进行灰度，分别是不同的存取逻辑。如果存储时使用了V1版本的API而获取时使用V2版本的API，那么就可能出现用户注册成功后反而返回注册失败消息的诡异问题。  如何实现一套灰度发布系统
　　前面也提到了，提供给用户的接口大概可以分为和业务绑定的简单灰度判断逻辑。以及输入稍微复杂一些的哈希灰度。我们来分别看看怎么实现这样的灰度系统（函数）。  业务相关的简单灰度
　　公司内一般都会有公共的城市名字和id的映射关系，如果业务只涉及中国国内，那么城市数量不会特别多，且id可能都在10000范围以内。那么我们只要开辟一个一万大小左右的bool数组，就可以满足需求了：  var cityID2Open = [12000]bool{}  func init() {     readConfig()     for i:=0;i= 100 {         return true     }      if rate > 0 && rand.Int(100) > rate {         return true     }      return false }
　　注意初始化种子。  哈希算法
　　求哈希可用的算法非常多，比如md5，crc32，sha1等等，但我们这里的目的只是为了给这些数据做个映射，并不想要因为计算哈希消耗过多的cpu，所以现在业界使用较多的算法是murmurhash，下面是我们对这些常见的hash算法的简单benchmark。
　　下面使用了标准库的md5，sha1和开源的murmur3实现来进行对比。  package main  import (     ＂crypto/md5＂     ＂crypto/sha1＂      ＂github.com/spaolacci/murmur3＂ )  var str = ＂hello world＂  func md5Hash() [16]byte {     return md5.Sum([]byte(str)) }  func sha1Hash() [20]byte {     return sha1.Sum([]byte(str)) }  func murmur32() uint32 {     return murmur3.Sum32([]byte(str)) }  func murmur64() uint64 {     return murmur3.Sum64([]byte(str)) }
　　为这些算法写一个基准测试：  package main  import ＂testing＂  func BenchmarkMD5(b *testing.B) {     for i := 0; i < b.N; i++ {         md5Hash()     } }  func BenchmarkSHA1(b *testing.B) {     for i := 0; i < b.N; i++ {         sha1Hash()     } }  func BenchmarkMurmurHash32(b *testing.B) {     for i := 0; i < b.N; i++ {         murmur32()     } }  func BenchmarkMurmurHash64(b *testing.B) {     for i := 0; i < b.N; i++ {         murmur64()     } }
　　然后看看运行效果：  ~/t/g/hash_bench git:master ❯❯❯ go test -bench=. goos: darwin goarch: amd64 BenchmarkMD5-4          10000000 180 ns/op BenchmarkSHA1-4         10000000 211 ns/op BenchmarkMurmurHash32-4 50000000  25.7 ns/op BenchmarkMurmurHash64-4 20000000  66.2 ns/op PASS ok _/Users/caochunhui/test/go/hash_bench 7.050s
　　可见murmurhash相比其它的算法有三倍以上的性能提升。显然做负载均衡的话，用murmurhash要比md5和sha1都要好，这些年社区里还有另外一些更高效的哈希算法涌现，感兴趣的读者可以自行调研。  分布是否均匀
　　对于哈希算法来说，除了性能方面的问题，还要考虑哈希后的值是否分布均匀。如果哈希后的值分布不均匀，那也自然就起不到均匀灰度的效果了。
　　以murmur3为例，我们先以15810000000开头，造一千万个和手机号类似的数字，然后将计算后的哈希值分十个桶，并观察计数是否均匀：  package main  import (     ＂fmt＂      ＂github.com/spaolacci/murmur3＂ )  var bucketSize = 10  func main() {     var bucketMap = map[uint64]int{}     for i := 15000000000; i < 15000000000+10000000; i++ {         hashInt := murmur64(fmt.Sprint(i)) % uint64(bucketSize)         bucketMap[hashInt]++     }     fmt.Println(bucketMap) }  func murmur64(p string) uint64 {     return murmur3.Sum64([]byte(p)) }
　　看看执行结果：  map[7:999475 5:1000359 1:999945 6:1000200 3:1000193 9:1000765 2:1000044  4:1000343 8:1000823 0:997853]
　　偏差都在1/100以内，可以接受。在调研其它算法，并判断是否可以用来做灰度发布时，也应该从本节中提到的性能和均衡度两方面出发，对其进行考察。