本文引用了阿豪的微信公众号文章分享,感谢原做者的分享。php
随着社会的发展、互联网技术的进步,之前的大型机服务端架构很显然因为高成本、难维护等缘由渐渐地变得再也不那么主流了,替代它的就是当下最火的互联网分布式架构。html
从若干年前大行其道的传统大型机到现在的分布式架构,技术发展已经经历了好几个阶段,咱们只有弄明白典型互联网架构在各个阶段的演进,才能更好地理解和体会分布式架构的好处,从而有助于咱们序设计适合于自已公司、产品或项目的架构(也包括设计即时通信网专一的IM和消息推送这类系统,由于技术思路的原理都是一脉相承的)。那么本文咱们就来聊聊分布式架构的演进过程,但愿能给你们带来眼前一亮的感受。java
点评:即时通信网做为IM和推送技术研究、学习和分享的社区,整理了大量的跟IM和推广技术有关的基础技术资料(好比网络基础、通讯理论、架构基础等),本文内容虽然看起来跟IM和推送技术没有直接的关联性,但由于设计IM和推送系统的技术思路和原理跟典型大型互联网分布式架构都是一脉相承的,于是读懂本文内容对于IM和推送系统的架构设计一样大有裨益。mysql
学习交流:程序员
- 即时通信开发交流3群:185926912[推荐]web
- 移动端IM开发入门文章:《新手入门一篇就够:从零开发移动端IM》redis
(本文同步发布于:http://www.52im.net/thread-2007-1-1.html)算法
若是你已彻底掌握本文的相关知识,请移步继续阅读即时通信网整理的另外一篇:《腾讯资深架构师干货总结:一文读懂大型分布式系统设计的方方面面》,该文适合对互联网架构知识有必定了解的程序员阅读和学习,都是不可能多得的技术干货。sql
咱们都知道一个成熟的大型网站的系统架构并不是一开始就设计的很是完美,也没有一开始就具有高性能、高并发、高可用、安全性等特性,而是随着用户量的增长、业务功能的扩展逐步演变过来的,慢慢的完善的。 在这个过程当中,开发模式、技术架构等都会随着迭代发生很是大的变化。 而针对不一样业务特征的系统,各自都会有本身的侧重点,例如像淘宝这类的网站,要解决的重点问题就是海量商品搜索、下单、支付等问题; 像腾讯这类的网站,要解决的是数亿级别用户的实时消息传输;而像百度这类的公司所要解决的又是海量数据的搜索。每个种类的业务都有本身不一样的系统架构。数据库
为了方便展开本文要讲解的内容,咱们来简单模拟一个架构演变过程: 咱们以 javaweb 为例,来搭建一个简单的电商系统,从这个系统中来看系统的演变过程。要注意的是接下来的演示模型, 关注的是数据量、访问量提高,网站结构的变化, 而不关注具体业务的功能点。其次,这个过程是为了让你们能更好的了解网站演进过程当中的一些问题和应对策略。
假如咱们要设计的互联网系统须要具有如下功能:
1)用户模块:用户注册和管理;
2)商品模块:商品展现和管理;
3)交易模块:建立交易及支付结算。
请带着上述3个技术点,继续深刻阅读本文的正文内容。干货立刻开始了。。。
如上图所示,这个阶段是网站的初期,也能够认为是互联网发展的早期,系统架构如上图所示。咱们常常会在单台服务器上运行咱们全部的程序和软件。 把全部软件和应用都部署在一台机器上,这样就完成一个简单系统的搭建,这个阶段的讲究的是效率。效率决定生死。
随着网站的上线,访问量逐步上升,服务器的负载慢慢提升,咱们应该在服务器尚未超载的时候就作好规划、提高网站的负载能力。倘若此时已经没办法在代码层面继续优化提升,那么在单台机器的性能遇到瓶颈的时候,增长机器是一个比较简单好用的方式,投入产出比至关高。这个阶段增长机器的主要目的是将 web 服务器和 数据库服务器拆分开来,这样作的话不只提升了单机的负载能力,也提升了整个系统的容灾能力。
这个阶段的系统架构如上图所示,应用服务器和数据库服务器彻底隔离开来,相互互不影响,大大减小了网站宕机的风险,此阶段咱们已经开始关注到应用服务器的管理了。
这个阶段,随着访问量的继续不断增长,单台应用服务器已经没法知足咱们的需求。 假设个人数据库服务器尚未遇到性能问题,那咱们能够经过增长应用服务器的方式来将应用服务器集群化,这样就能够将用户请求分流到各个服务器中,从而达到继续提高系统负载能力的目的。此时各个应用服务器之间没有直接的交互,他们都是依赖数据库各自对外提供服务。
系统架构发展到这个阶段,各类问题也会接踵而至:
1)用户请求交由谁来转发到具体的应用服务器上(谁来负责负载均衡);
2)用户若是每次访问到的服务器不同,那么如何维护session,达到session共享的目的。
那么此时,系统架构又会变成以下方式:
负载均衡又能够分为软负载和硬负载。软负载咱们能够选择Nginx、Apache等,硬负载咱们能够选择F5等。而session共享问题咱们能够经过配置tomcat的session共享解决。
架构演变到上面的阶段,并非终点。经过上面的设计,应用层的性能被咱们拉上来了, 但数据库的负载也在逐渐增大,那如何去提升数据库层面的性能呢?有了前面的设计思路之后,咱们天然也会想到经过增长服务器来提升性能。但假如咱们单纯的把数据库一分为二,而后对于数据库的请求,分别负载到两台数据库服务器上,那一定会形成数据库数据不统一的问题。
因此咱们通常先考虑将数据库读写分离,以下图所示。
这个架构设计的变化会带来以下几个问题:
1)主从数据库之间的数据须要同步(可使用 mysql 自带的 master-slave 方式实现主从复制 );
2)应用中须要根据业务进行对应数据源的选择( 采用第三方数据库中间件,例如 mycat )。
咱们都知道数据库经常对模糊查找效率不是很高,像电商类的网站,搜索是很是核心的功能,即便是作了读写分离,这个问题也不能获得有效解决。那么这个时候咱们就须要引入搜索引擎了,使用搜索引擎可以大大提高咱们系统的查询速度,但同时也会带来一 些附加的问题,好比维护索引的构建、数据同步到搜索引擎等。
而后,随着访问量的持续不断增长,逐渐会出现许多用户访问同一内容的状况,那么对于这些热点数据,不必每次都从数据库重读取,这时咱们可使用到缓存技术,好比 redis、memcache 来做为咱们应用层的缓存。
另外在某些场景下,如咱们对用户的某些 IP 的访问频率作限制, 那这个放内存中就又不合适,放数据库又太麻烦了,那这个时候可使用 Nosql 的方式好比 mongDB 来代替传统的关系型数据库。
咱们的网站演进的变化过程,交易、商品、用户的数据都还在同一 个数据库中,尽管采起了增长缓存,读写分离的方式,可是随着数 据库的压力持续增长,数据库的瓶颈仍然是个最大的问题。所以我 们能够考虑对数据的垂直拆分和水平拆分。
垂直拆分:把数据库中不一样业务数据拆分到不一样的数据库;
水平拆分:把同一个表中的数据拆分到两个甚至更多的数据库中,水平拆分的缘由是某些业务数据量已经达到了单个数据库的瓶颈,这时能够采起将表拆分到多个数据库中。
随着业务的发展,业务量愈来愈大,应用的压力愈来愈大。工程规模也愈来愈庞大。这个时候就能够考虑将应用拆分,按照领域模型将咱们的用户、商品、交易拆分红多个子系统。
这样拆分之后,可能会有一些相同的代码,好比用户操做,在商品和交易都须要查询,因此会致使每一个系统都会有用户查询访问相关操做。这些相同的操做必定是要抽象出来,不然就是一个坑。因此经过走服务化路线的方式来解决。
那么服务拆分之后,各个服务之间如何进行远程通讯呢? 经过 RPC 技术,比较典型的有:dubbo、webservice、hessian、http、RMI 等等。前期经过这些技术可以很好的解决各个服务之间通讯问题,可是, 互联网的发展是持续的,因此架构的演变和优化也还在持续。
经过本文,咱们经过一个电商的案例,就了解到了分布式架构的演进过程,一环套一环,环环紧密相扣。都是经过业务量和访问量的提高来考虑重构架构设计,以便可以适应当前的环境。不可一蹴而就,也急不来,初创企业必须稳扎稳打,一步一个脚印的走出一条专属本身的路。
本文主要针对的是零基础初学者,若是您想深刻了解相关知识,请继续阅读《腾讯资深架构师干货总结:一文读懂大型分布式系统设计的方方面面》。
《一套海量在线用户的移动端IM架构设计实践分享(含详细图文)》
《IM开发基础知识补课(二):如何设计大量图片文件的服务端存储架构?》
《IM开发基础知识补课(三):快速理解服务端数据库读写分离原理及实践建议》
《IM开发基础知识补课(四):正确理解HTTP短链接中的Cookie、Session和Token》
《WhatsApp技术实践分享:32人工程团队创造的技术神话》
《王者荣耀2亿用户量的背后:产品定位、技术架构、网络方案等》
《IM系统的MQ消息中间件选型:Kafka仍是RabbitMQ?》
《腾讯资深架构师干货总结:一文读懂大型分布式系统设计的方方面面》
《子弹短信光鲜的背后:网易云信首席架构师分享亿级IM平台的技术实践》
《知乎技术分享:从单机到2000万QPS并发的Redis高性能缓存实践之路》
《IM开发基础知识补课(五):通俗易懂,正确理解并用好MQ消息队列》
《微信技术分享:微信的海量IM聊天消息序列号生成实践(算法原理篇)》
《微信技术分享:微信的海量IM聊天消息序列号生成实践(容灾方案篇)》
《新手入门:零基础理解大型分布式架构的演进历史、技术原理、最佳实践》
>> 更多同类文章 ……
(本文同步发布于:http://www.52im.net/thread-2007-1-1.html)