青海城乡建设厅网站,网站分类有哪几类,app安装软件下载,微网站 布局虽然这篇文章写的比较早#xff0c;但是#xff0c;还是很有参考意义#xff0c;值得好好品读思考。看看别人是怎么思考就架构这种事情。 好的架构不是设计出来的而是演进出来的 对很多创业公司而言#xff0c;在初期的时候#xff0c;我们很难在初期就预估到流量十倍以后…虽然这篇文章写的比较早但是还是很有参考意义值得好好品读思考。看看别人是怎么思考就架构这种事情。 好的架构不是设计出来的而是演进出来的 对很多创业公司而言在初期的时候我们很难在初期就预估到流量十倍以后、百倍以后、一千倍以后网站的架构会变成什么样。当然如果在最初的时期就设计一个千万级并发的流量架构那样的话成本是也是非常之高的估计很难有公司会这样做。 所以我们主要来讲架构是如何进行演化的。我们在每个阶段找到对应该阶段网站架构所面临的问题然后在不断解决这些问题的过程中整个战略的架构就是在不断的演进了。 其实在 58 同城建立之初站点的流量非常小可能也就是是十万级别这也就意味着平均每秒钟也就是几次的访问。此时网站架构的特点请求量是比较低数据量比较小代码量也比较小。可能找几个工程师很容易就做一个这样的站点根本没什么「架构」可言。 其实这也是很多创业公司初期面临的问题最开始58同城的站点架构用一个词概括就是「ALL IN ONE」如下图所示 就像一个单机系统所有的东西都部署在一台机器上包括站点、数据库、文件等等。而工程师每天的核心工作就是 CURD前端传过来一些数据然后业务逻辑层拼装成一些 CURD 访问数据库数据库返回数据数据拼装成页面最终返回到浏览器。相信很多创业团队初期做的工作也是类似每天写代码写 SQL、接口参数、访问数据等等。 这里需要说明一个问题大家都知道目前 58 同城使用的是 Windows、iis、SQL-Sever、C# 这条路。现在很多创业公司可能就不会这么做。58 同城为什么当时选择了这条路原因是公司招聘的第一个工程师和第二个工程师只会这个所以只能走这条路。 如果可以重来那么会选择LAMP 很多创业的同学可能会想如果我们初期希望做一个产品的话我们应该使用什么架构 如果让我们重来可能我们现在会选 LAMP为什么首先是无须编译而且快速发布功能强大从前端到后端、数据库访问、业务逻辑处理等等全部可以搞定最重要的是因为开源产品是完全免费的。如果使用 LAMP 搭建一个论坛两天的时间就很足够了。所以如果在创业初期就尽量不要再使用 Windows 的技术体系了。 在这个阶段 58 同城面临的主要问题是什么其实就是招人。很多工程师可能都是再培训学校里培训了3月就过来上班所以他们写 CURD 的话很容易出错。当时我们引进了 DAO 和 ORM。虽然那些培训了几个月的工程师可能写CURD不是特别的擅长但是他们写面向对象的一些程序引入了 DAO 和 ORM让他们不再直接面对 CURD 语句这样就会相对容易一些。因为工程师比较擅长的是面向对象的数据不是 CURD所以我们当时引入了 ORM总的来说如果大家现在的项目处于一个初期孵化的阶段DAO 和 ORM 能够极大的提高效率而且可以降低出错的概率。 中等规模流量跨过十万的阶段数据库成为瓶颈 随着 58 同城的高速增长我们很快跨越了十万流量的阶段。主要需求是什么网站能够正常访问当然速度更快点就好了。而此时系统面临问题包括在流量的高峰期容易宕机因为大量的请求会压到数据库上所以数据库成为新的瓶颈而且人多的时候访问速度会很慢。这时我们的机器数量也从一台变成了多台。现在的架构就采用了分布式如下图所示 首先我们使用了一些非常常见的技术一方面是动静分离动态的页面通过 Web-Servre 访问静态的像图片等就单独放到了一些服务器上。另外一点就是读写分离。其实对 58 同城或者说绝大部分的站点而言一般来说都是读多写少。对 58 同城来说绝大部分用户是访问信息只有很少的用户过来发贴。那么如何扩展整个站点架构的读请求呢常用的是主从同步读写分离。我们原来只有一个数据库现在使用多个不同的数据库提供服务这样的话就扩展了读写很快就解决了中等规模下数据访问的问题。 在这个阶段系统的主要矛盾就是「站点耦合读写延时」58 同城是如何进行解耦如何缓解延时呢 对 58 同城而言典型业务场景是主页发布信息有发布页信息聚合、标题聚合有列表页点开一个标题有详细页而这些站点都是耦合在一个程序中的或者说耦合在一个站点中的当我们有一个站点出现问题的时候整个站点就会因为耦合一起出问题。 第二个问题大家都知道做数据库读请求和写请求分布在不同的数据库上这个时候如果再读取可能读到的是旧数据因为读写有一个延时。如果有用户发帖子马上去找的话肯定找不到很可能带来的后果就是陆续在发布两条信息这就是一个很大的问题。尤其是在请求量越来越大的时候这个问题就更加突出。 在解决这些问题是最先想到的是针对原来站点的核心业务做切分然后工程师根据自己的站点和业务场景进行细分。首先业务拆分是 58 同城最先尝试的优化。我们将业务垂直拆分成了首页和发布页。另外在数据库层面我们也随之进行了拆分将大数据量拆分成一个个小的数据量。这样读写延时就马上得到了缓解。尤其是在代码拆分成了不同的层面之后站点耦合也得到了缓解数据量加载速度也提升了很多。 当时还使用了一些技术前面也提到了对动态资源和静态资源进行拆分。其中我们对静态资源使用了 CDN 服务便于数据缓存和就近访问访问速度得到很明显的提升。除此之外我们还使用了 MVC 模式擅长前端的去做展示层擅长协作逻辑的工程师就做 Contorller擅长数据的人就负责数据效率就会逐步的提高最后就是负载均衡技术。 大流量将整个 Windows 技术体系转向了 Java 体系 流量越来越大当流量超过一千多万时58 同城面对最大的问题就是性能和成本。此前我提到58同城最初的技术选型是 Windows应该是在 2006 年的时候整个网站的性能变得非常之低。即使进行了业务拆分和一些优化但是依然解决不了这个问题所以我们当时做了一个非常艰难的决定就是转型将整个 Windows 技术体系转向了 Java 体系这涵盖了操作系统、数据库等多个维度。 其实现在很多大的互联网公司在流量从小到大的过程中都经历过转型包括京东、淘宝等等。对技术的要求越来越高任何一个站点都不能挂对站点的可用性要求也是越来越高。 就在这个时候58 同城业务量也出现一个爆发期。于是我们招聘了很多的工程师大家一起写越来越多的站点但是发现效率很低经常做一些重复性的工作比如参数解析等等。同时业务之间相互依赖无论是分类的子系统还是信息的子系统二手车业务、房产业务都要访问用户和信息等一些底层数据代码之间频繁的沟通效率也不可能很高。 问题随之而来站点数越来越多数据量越来越大机器数从最开始的几台上升到几百台的级别。那么如何提供整个架构的可用性呢首先在上层我们进行了一些改进和优化再做进一步的垂直拆分同时我们引入了 Cache如下图所示 在架构的改进上我们构建了一个相对独立的服务层这个服务层做的每个业务线都会写对应的代码。如果用户发出请求就由这个服务层统一来管理所有的上游业务线就像调用本地函数一样通过 IDC 的框架来调用这个服务。整个用户登录先访问 Cache如果 Cache 变动了就直接返回如果 Cache 不变动就会访问数据库这样把数据库的数据拿到本地再放回 Cache再打回上一轮。如此一来业务逻辑全部封装在这个服务的上游管理该业务逻辑只有服务层能够编写代码然后由这个服务层集中管理、集中优化这样就提高了效率。 除此之外为了保证站点的高可用我们主要使用了反向代理技术。因为用户而言他主要为了使用 58 同城的服务他不关注访问是58同城或者有十台首页的服务器。58 同城通过反向代理技术通过 DNS 群通过 LVS 技术来保证接入层的高可用性同时还保证了服务层、站点层、数据层的高可用。另外为了保证高可用我们经常使用冗余的方法无论是站点服务和数据服务都可以使用这种方式进行解决一个站点不可用我们就换一个站点一个数据库不够用我们就多加几个。当然数据冗余也会带来一些副作用如果数据量更新的话那就需要将所有的“冗余”都要进行更新。 58同城也做了一个图片存储系统开始都是存储在操作系统之上随着新增站点、新增服务压力就变得越来越大。于是58 同城就自建了站点框架和服务框架现在这两个框架也已经开源如何降低站点开发成本https://github.com/58code/Argo 如何降低服务开发成本 https://github.com/58code/Gaea 只需要修改一些基本的配置就可以使用了。 当架构变成「蜘蛛网」人肉已很难搞定 随着用户量、数据量并发量进一步的增长58同城也拓展了很多的新业务那么对产品迭代速度要求就非常高整体的架构对自动化的要求越来越高。 为了支撑业务的发展技术团队对架构做了进一步的解耦另外就是引入了配置中心如果要访问任何一个服务不会直接在本地的配置中留下一个服务配置中心告诉这个服务的特点如果扩展的话配置中心自动下达消息如果有机器要下线的话配置中心会反向通过发邮件的方式进行通知。 而柔性服务是指当流量增加的时候自动的新增服务。可以看到进一步解耦之后有垂直业务、无线业务、集成业务等等这些子系统之间都是通过配置中心相应之间发生关系的。 另一点就是关于数据库当某一点成为一个业务线重点的时候我们就会集中解决这个点的问题。最初期的时候每个业务线都要访问数据库访问缓存访问用户数据于是我们把代码集中的放到了服务层。现在数据量越来越大大家都要做数据切分每个业务线都做切分这个时候58同城的每个页面都面对这样的痛点于是把这个痛点拿到集中的层面来解决。 最后一点就是效率矛盾此时很多问题靠「人肉」已经很难进行搞定了。这就需要自动化包括回归、测试、运维、监控等等都要回归到自动化。 这里需要补充一点就是在产品层面我们引入了智能化比如说智能推荐主动推荐一些相关的话题智能广告通过一些智能的策略让用户对广告的点击更多增加对 58 同城的收录智能搜索在搜索的过程中加入一些搜索的策略可以提高搜索的权重也可以增加 58 同城的 PV。当然所有的自动化的产品背后都是由技术在驱动。 未来的挑战 现在58同城的流量已经突破的 10 亿的量级那么架构上未来面临哪些挑战呢一方面是无线化、移动化。另一方面就是需求的变化我们必须加快迭代一些东西。如果拥有10亿的流量却跑在一亿的架构上肯定是不行的。未来我们会使用更多的并行计算、实时计算如果能做到实时推荐效果肯定非常好这也是我们的挑战。最后一点58同城现在的服务器大概在3000台左右未来将拓展到 10000 万这就是运维的挑战了。 总结 最后做一个小的总结网站在不同的阶段遇到的问题不一样而解决这些问题使用的技术也不一样流量小的时候我们主要目的是提高开发效率在早期要引入 ORMDAO 这些技术。随着流量变大使用动静分离、读写分离、主从同步、垂直拆分、CDN、MVC 等方式不断提升网站的稳定性。面对更大的流量时通过垂直拆分、服务化、反向代理、开发框架站点/服务等等不断提升高可用。在面对上亿级的更大流量时通过中心化、柔性服务、消息总线、自动化回归测试运维监控来迎接新的挑战。未来的就是继续实现 移动化大数据实时计算平台化… 本文系「OneAPM 技术公开课」第一期演讲嘉宾沈剑演讲整理。「 OneAPM 技术公开课」由应用性能管理第一品牌 OneAPM 发起内容面向 IT 开发和运维人员。云集技术牛人、知名架构师、实践专家共同探讨技术热点。继北京站、上海站第火爆上演之后第三场将于 10 月 31 日在北京、成都「双城」上演新一轮的「性能之战」。 from: http://blog.oneapm.com/apm-tech/203.html转载于:https://www.cnblogs.com/jiujuan/p/11073704.html
