花了两天时间扫了下，后面的列传没仔细看，整个的文风就是个 BBS 八卦体，写的很有趣味，对互联网从业人员也很有启发性，是本好书。下面记录下一些乱七八糟的思绪。
淘宝一开始创业的技术并不高明，虽然有很多牛人，但感觉也只是很勤奋而已（个人觉得甚至有点矬，比如那个重启 sql relay 的活儿，哥啊，你们真的没整个自动监测并重启的脚本？另一个例子是没搞定 php 的数据库连接池），没搞出啥“纯技术”上的大名堂。成功关键还在于马云的商业头脑，抓住商机。这并不是说“技术顶个球”，技术虽然不是第一，但也不是倒数第一。
淘宝开始的很早，很多开源技术还没出现或者不被人所知，如果今天开始做的话，可能有很多东西会直接拿来用或者改进了，比如 memcache，redis, voldemort, kafka, storm, thrift + twitter finagle.
一开始如果能多考虑点可扩展的架构，日后一旦壮大，重构会不那么痛苦。具体实现视情况打折扣，理想实现是即使在单机上也按照分布式应用思路做，但肯定没办法这么理想，进度所迫，产品设计总在变化，需求总在变。无论如何，一开始完全不考虑一味求糙快猛是愚蠢的，忽视业界经验，尤其是这本书讲到的经验，有可能日后中道崩殂。
技术对了，产品设计对了，未必能成功，因为时机可能不对，用户一时接受不了。
好的设计是磨练出来的，再好的架构师也没法一锤定音，一方面是流量上来后各种未预料到的问题，另一方面是没有完全一模一样的需求，各种未预料到的需求。即使如此，互联网行业的系统架构还是有粗略套路可循的，因为同一行业内要解决的事情总有类似的。
可供参考的技术，不完全是书中提到的。
-
- 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 也能避免单点故障。
- 在展现层上免不了走两条路子：服务端模板技术，在服务端全渲染好；AJAX 方式。虽然两者并不排斥，但个人觉得 AJAX 方式优雅的多，一开始就把 service 和 UI 分离开了，开发也容易，前端工程师和后端工程师不用在模板文件上打架。
- 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
- service registry，这是每个创业公司一开始都会忽视的东西，而一旦壮大后都必需得做，尤其是把各种功能分割到不同子系统成为服务之后。
- RPC framework: thrift, twitter finagle
- 关系数据库：MySQL, PostgreSQL
- 这俩数据库都是单机版本，要达到集群效果需要做大量工作：分库分表、join、分页、事务、failover、负载均衡，尽可能自动化的导入导出、增减实例，目测只有 Google、Facebook和淘宝玩的很溜。
- NoSQL: HBase, Cassandra, Riak, RethinkDB, CouchBase，Voldemort
- 小文件存储：TFS，MogileFS, FastDFS
扫一扫
861
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
