好架构是进化来的,不是设计来的(58架构演进).pdfVIP

好架构是进化来的，不是设计来的 （58架构演进） 好的架构化是进化⽽来的，不是设计出来的 58沈剑 核⼼内容：58同城流量从⼩到⼤过程中，架构是如何演进的？遇到了哪些问题？以 如何解决这些问题？ 核⼼观点：好的架构不是设计出来的，⽽是进化⽽来的。 如何演进：站点流量在不同阶段，会遇到不同的问题，找到对应阶段站点架构所⾯临 的主要问题，在不断解决这些问题的过程中，整个系统的架构就不断的演进了。 如何演进，简⾔之：找到主要⽭盾，并解决主要⽭盾。 第⼀章：建站 初 建站之初，站点流量⾮常⼩，可能低于⼗万级别。这意味着，平均每秒钟也就⼏次访 问。请求量⽐较低，数据量⽐较⼩，代码量也⽐较⼩，⼏个⼯程师，很短的时间搭起 这样的系统，甚⾄没有考虑“架构”的问题。 和许多创业公司初期⼀样，最初58同城的站点架构特点是“ALL-IN-ONE” ： 这是⼀个单机系统，所有的站点、数据库、⽂件都部署在⼀台服务器上。⼯程师每天 的核⼼⼯作是CURD ，浏览器端传过来⼀些数据，解析GET/POST/COOKIE 中传过来 的数据，拼装成⼀些CURD的sql语句访问数据库，数据库返回数据，拼装成页⾯，返 回浏览器。相信很多创业团队的⼯程师，初期做的也是类似的⼯作。 58同城最初选择的是微软技术体系这条路：Windows、iis、SQL-S v r 、C# 如果重新再来，我们可能会选择LAMP体系。 为什么选择LAMP ？ LAMP⽆须编译，发布快速，功能强⼤，社区活跃，从前端+后端+数据库访问+业务 逻辑处理全部可以搞定，并且开源免费，公司做⼤了也不会有⼈上门收钱 （不少公司 吃过亏）。现在⼤家如果再创业，强烈建议使⽤LAMP 。 初创阶段，⼯程师⾯临的主要问题：写CURD的sql语句很容易出错。 我们在这个阶段引进DAO和ORM，让⼯程师们不再直接⾯对CURD的sql语句，⽽是 ⾯对他们⽐较擅长的⾯向对象开发，极⼤的提⾼了编码效率，降低了出错率。 第⼆章：流量增加，数据库成为瓶颈 随着流量越来越⼤，⽼板不只要求“有⼀个可以看见的站点” ，他希望⽹站能够正常访 问，当然速度快点就更好了。 ⽽此时系统⾯临问题是：流量的⾼峰期容易宕机，⼤量的请求会压到数据库上，数据 库成为新的瓶颈，⼈多并⾏访问时站点⾮常卡。这时，我们的机器数量也从⼀台变成 了多台，我们的系统成了所谓的 （伪）“分布式架构” ： 我们使⽤了⼀些常见优化⼿段： （1）动静分离，动态的页⾯通过W b-S rv r访问，静态的⽂件例如图⽚就放到单独的 ⽂件服务器上； （2 ）读写分离，将落到数据库上的读写请求分派到不同的数据库服务器上； 互联⽹绝⼤部分的业务场景，都是读多写少。对58同城来说，绝⼤部分⽤户的需求是 访问信息，有哪些信誉好的足球投注网站信息，只有少数的⽤户发贴。此时读取性能容易成为瓶颈，那么如何 扩展整个站点架构的读性能呢？常⽤的⽅法是主从同步，增加从库。我们原来只有⼀ 个读数据库，现在有多个读数据库，就提⾼了读性能。 在这个阶段，系统的主要⽭盾为“站点耦合+读写延时”，58同城是如何解决这两个问 题的呢？ 第⼀个问题是站点耦合。对58同城⽽⾔，典型业务场景是：类别聚合的主页，发布信 息的发布页，信息聚合的列表页，帖⼦内容的详细页，原来这些系统都耦合在⼀个站 点中，出现问题的时候，整个系统都会受到影响。 第⼆个问题是读写延时。数据库做了主从同步和读写分离之后，读写库之间数据的同 步有⼀个延时，数据库数据量越⼤，从库越多时，延时越明显。对应到业务，有⽤户 发帖⼦，马上去有哪些信誉好的足球投注网站可能有哪些信誉好的足球投注网站不到 （着急的⽤户会再次发布相同的帖⼦）。 要解决耦合的问题，最先想到的是针对核⼼业务做切分，⼯程师根据业务切分对系统 也进⾏切分：我们将业务垂直拆分成了⾸页、发布页、列表页和详情页。 另外，我们在数据库层⾯也进⾏了垂直拆分，将单库数据量降下来，让读写延时得到 缓解。 同时，还使⽤了这些技术来优化系统和提⾼研发效率： （1）对动态资源和静态资源进⾏拆分。对静态资源我们使⽤了CDN服务，⽤户就近 访问，静态资源的访问速度得到很明显的提升； （2 ）除此之外，我们还使⽤了MVC模式，擅长前端的⼯程师去做展⽰层，擅长业务 逻辑的⼯程师就做控制层，擅长数据的⼯程师就做数据层，专⼈专⽤，研发效率和质 量又进⼀步提⾼。 第三章：全⾯转型开源技术体系 流量越来越⼤，当流量达到百万甚⾄千万时，站点⾯临⼀个很⼤的问题就是性能和成 本的折衷。上⽂提到58同城最初的技术选型是Window