《超大流量分布式系统架构解决方案》学习笔记----第一章 大系统小做----大规模服务化架构

这系列的学习笔记不会粘贴复制书中的内容，更多的是我看了原文之后按照自己的理解，结合自己的项目经验谈自己的感悟。

互联网领域中的大规模系统往往都是一步一步演进的，不是一蹴而就的。从最初的单机架构，把应用服务、数据库服务、文件服务等都部署到一台服务器，再到，应用服务、数据库服务、文件服务等拆分到不同的服务器上。

更进一步的把应用服务按照业务情况拆分到不同的服务器上。

这个过程就是不断解耦的过程，实际上每解耦一次系统的风险就增加了一分。拆分出来的服务直接需要连接，连接就意味着不确定性和风险。这样就需要引入高可用，高可用简单点说就是同样的服务我挂两个，一个挂了，另外一个自动顶上去，保证服务不掉线，或者掉线时间很短。

大流量，大并发，就意味着要解耦流量，把1000份流量分到10台机器上，每台就只用处理100份流量。这里就衍生出API网关的技术了。API网关其实是一个概念，然后随着这个概念的不断发展，慢慢的就成为了单独的一个组件或者程序。

比如nginx 负载均衡，其实就是拿nginx做网关，把流量打到上游机器。出了负载均衡，频率控制、接口鉴权、黑白名单、安全防控、日志记录、灰度发布等等功能都抽象到API网关这层来做了。

可能原先我们要做日志统计，需要把nginx日志文件拿出来分析，需要做频率控制会在API接口里面增加相应的频率限制功能。然后慢慢的我们把这块功能统一剥离出来，让业务层更多的去关系业务本身。

这里推荐API网关Kong, 主要是自己最近在学，它的功能也很强大 https://www.zhihu.com/topic/20174970/hot
 

讲下我最开始接触一些高并发的解决方案时候的感受吧。

当时看了这些方案，就感觉卧槽，很牛X, 真希望能够马上在项目中用上，记得到当时有个项目，用户量不是很多，业务服务和数据库是独立部署的，我开始想着说能不能上个数据库读写分离，nginx负载均衡。当时一个技术同事直接否决了我，我们的用户量不高，用不上这些技术，还有很多业务代码需要去写，而且这些技术是有维护成本的，计算用户量起来了，最省成本的方案反而是直接升级服务器。

确实如他所说，再业务量还比较小的时候没必要用很复杂的技术。小公司最大的成本是人力成本，瓶颈在业务功能的实现上而不是性能优化。如果升级服务器每个月增加几千块钱的成本，而如果采用复杂的技术需要至少增加一个技术，成本是一万多每个月，反而不划算。

后来慢慢的接触到了百万级用户量的产品，其实现在来看用户量其实也不算太大。负载均衡+mysql读写分离的架构错错有余。但是随之而来的副作用就来了。当时线上需要排查一个bug，必须要先把3台业务服务器上的日志文件down下来一个一个的找。如果是一台业务服务器，那么问题的复杂度是1,3台业务服务器问题的复杂度一下子变成了3倍。

现在来看的话，单纯的nginx负载均衡这样的技术还不够，还需要日志收集统一到一个数据库这样方便排查线上bug。所以，一个技术的引进带来了其他的问题，有需要用其他的技术来解决新引入的技术带来的副作用。

所以完整的API网关技术再这种高并发架构显得十分重要。