淘宝技术这十年

http://www.cnblogs.com/DjangoBlog/p/3535452.html

淘宝开始的很早，很多开源技术还没出现或者不被人所知，如果今天开始做的话，可能有很多东西会直接拿来用或者改进了，比如 memcache，redis, voldemort, kafka, storm, thrift + twitter finagle.

一开始如果能多考虑点可扩展的架构，日后一旦壮大，重构会不那么痛苦。具体实现视情况打折扣，理想实现是即使在单机上也按照分布式应用思路做，但肯定没办法这么理想，进度所迫，产品设计总在变化，需求总在变。无论如何，一开始完全不考虑一味求糙快猛是愚蠢的，忽视业界经验，尤其是这本书讲到的经验，有可能日后中道崩殂。

技术对了，产品设计对了，未必能成功，因为时机可能不对，用户一时接受不了。

好的设计是磨练出来的，再好的架构师也没法一锤定音，一方面是流量上来后各种未预料到的问题，另一方面是没有完全一模一样的需求，各种未预料到的需求。即使如此，互联网行业的系统架构还是有粗略套路可循的，因为同一行业内要解决的事情总有类似的。

可供参考的技术，不完全是书中提到的。

1. load balancing + high availability
• DNS server 根据客户端的 IP 对应的地理位置对同一域名解析出不同的 IP 地址，以把用户请求导向不同的机房；
• 在页面里嵌入一段 JS 脚本，同时请求多个机房的某相同资源，服务端可以记录下请求日志，然后经由后台的日志分析系统分析出这个客户端请求哪个机房最快，这个信息可以用来改进上面的第一种办法；
• 在域名解析完成后，客户端的请求被发送到指定 IP 上，这个 IP 上部署 LVS(工作在 OSI 网络模型第四层)，LVS 后面部署 HAProxy(工作在 OSI 网络模型第七层)，两层一起做 load balancer，综合 LVS 的高效以及 HAProxy 的丰富特性。
• Apache 和 Nginx 也有 proxy 功能，但术业有专攻，流量特别大的时候效率肯定还是比不上 HAProxy
• 各位看官，貌似不要 LVS 也行吧? HAProxy 加上 keepalived or pacemaker + corosync/heartbeat 也能避免单点故障。
2. edge cache: Apache Traffic Server, Squid, Varnish，用来缓存静态内容或者一段时间内不变的动态内容
3. http server:  Nginx, Apache, Tomcat, Jetty
• 在展现层上免不了走两条路子：服务端模板技术，在服务端全渲染好；AJAX 方式。虽然两者并不排斥，但个人觉得 AJAX 方式优雅的多，一开始就把 service 和 UI 分离开了，开发也容易，前端工程师和后端工程师不用在模板文件上打架。
4. session persistence
• session ID
• cookie
• url parameter，比如 JSESSIONID=xxx
• session 的存储
• 直接把信息放在 cookie 里，QPS 高时带宽浪费严重
• http server 本地磁盘，需要 load balancer 支持 sticky session，单个 http server 崩溃会丢失 session 数据
• global session storage: redis, rdbms + memcache
5. RPC system，切分各个服务后，服务之间需要统一而且高效的 RPC 机制
• service registry，这是每个创业公司一开始都会忽视的东西，而一旦壮大后都必需得做，尤其是把各种功能分割到不同子系统成为服务之后。
• RPC framework:  thrift, twitter finagle
6. cache:  memcache, redis, tair, voldemort
7. storage: 分布式存储应该是整个技术栈里最难的部分了。
• 关系数据库：MySQL, PostgreSQL
• 这俩数据库都是单机版本，要达到集群效果需要做大量工作：分库分表、join、分页、事务、failover、负载均衡，尽可能自动化的导入导出、增减实例，目测只有 Google、Facebook和淘宝玩的很溜。
• NoSQL: HBase, Cassandra, Riak, RethinkDB, CouchBase，Voldemort
• 小文件存储：TFS，MogileFS, FastDFS
8. 消息队列：这类产品多如牛毛，但能同时支持至少一次、至多一次、保序特性的还是不多。多提一句的是 Redis 集群（官方的抑或各种山寨的）都是 AP 系统，不是 CP 系统，作为 queue 不适合严肃场合(作为 storage 也如此)
9. 任务队列：Gearman, Celery
10. 系统监测：Nagios, Ganglia, Graphite, statsd
11. 日志收集：Kafka, Flume, Fluentd, Kibana，LinkedIn 的实践非常值得参考，尤其值得一提的是 schema registry 的概念，没有这个服务，很难利用收集的数据。
12. 数据分析：Hadoop, Storm, Spark, Presto
13. 自动化部署：Puppet, Chef, Ansible 等。