036 互联网的框架演变

　　最新要写这个方面的知识，而后，发现网上的知识层次不一，至于怎么整理，也是一件比较头疼的事情。

　　因此，在这里，先列举出一些比较好的整理。最后，在此基础上，进行梳理成本身的文档。

一：这个是从开始到目前演变中针对技术作的总结

1.说明：

　　大型网站的技术挑战主要来自于庞大的用户，高并发的访问和海量的数据，任何简单的业务一旦须要处理数以P计的数据和面对数以亿计的用户，问题就会变得很棘手。大型网站架构主要就是解决这类问题

 

2.各个阶段的技术

　　最开始的网站

　　　　

 

　　第一步：物理分离应用数据库

          网站运营的最开始阶段，在天天高峰期的时候老是会出现宕机现象而且常常会有数据库和网站应用挣抢硬件资源的情况出现，这种状况下，最简单的方案就是把应用和数据库分开部署到不一样机器上，以提升各自可以占有的资源。

　　　　

 

          第二步：页面缓存和静态化

          随着网站访问量的迅猛攀升，系统的响应会开始变慢，主要缘由是由于访问数据库的链接增多，数据库服务器的硬件配置又决定了只能提供必定数量的链接。因为网站里的不少内容是不多更新的。因而能够把这些页面缓存起来或者静态化，减小对数据库的访问。这一步对技术上有所要求：页面缓存技术，模板技术。页面缓存提议Squid等几种方案，静态化可经过生成静态HTML方式实现。 

           第三步：页面片断缓存

           页面片断缓存可采用ESI、OSCacheD等框架来进行实现。

           第四步：数据缓存

           数据缓存可采用ehcache、OSCache或独立实现的缓存框架来实现。这步演变对技术上的要求：Map数据结构、程序语言中的Map数据结构（例如JAVA中的HashMap、TreeMap等）、所采用的缓存框架的实现方式（缓存内容的存储方式、查找算法和失效算法）

           第五步：水平扩展应用服务器

           若是单纯是访问量高形成了服务器压力过大，那就只能采用增长应用服务器，进入水平扩展阶段。那么如何让访问平均分配到每台应用服务器上。这里先用软件负载均衡技术。软件负载均衡技术可选：DNS轮询、Apahce、Nginx、LVS等。又如何保持信息同步呢，如session同步。可采用信息写入数据库、写入共享文件、cookie或在各台机器上同步状态信息等。如何保证数据缓存的同步？可采用缓存同步或分布式缓存。如何让文件相关的功能继续可用 ，例如文件上传功能等。可采用共享文件系统或存储设备，采用前者的居多一些。这一步须要积累的知识有1.负载均衡技术，包括但不限于硬件负载金衡技术（四层，七层等）、软件负载均衡技术、负载均衡算法、转发协议、（如VS/NAT、VS/TUN、VS/DR）所选用的技术的实现细节（如LVS的实现）等。2.容灾技术，包括但不限于ARP、Linux Heart-beanting等。3.状态信息或缓存同步技术，包括但不限于cookie、UDP协议、组播、数据同步框架的实现（例如jgroups等）。4.共乡文件原理,如NFS等

　　　　

 

            第六步：分库

            以上工做完成后，你的团队能够作各类各样的小调优工做，例如操做系统调优、Apache调优、JVM调优等等。分库的实现对技术没有过高的要求，仅在于整理业务，进行拆分，并相应的对程序进行适当的修改。

            第七步：分表、DAL、分布式缓存

            因为数据库数据量太大，分库每每不可以解决系统缓慢，这时，须要采起适当的分表和数据库调优，因为服务器没有那么多内存能够提供缓存，因此开始采用分布式缓存。问题： 在进行分表时，发现很明显的问题：分表后致使访问数据库的程序复杂度提升。由于在查表时必然要先考虑分表规则。要将这一层统一 ，最好的办法就也就是著名的DAL。增长数据访问层。分布式缓存可采用的方案有memcache、JbossCache等。分表时应作的知识储备：动态Hash、Consistent Hash 、分布式缓存实现原理、数据库链接管理、数据库操做的控制等。

　　　　

            第八步：改变应用服务器水平扩展环境

            当Apache、nginx或LVS等软件负载均衡方式已经没法承受巨大的访问量的调度压力时，可考虑购买硬件负载均衡设备。如F五、Netsclar、Athlon等，也可从业务角度进行划分，构建不一样的业务软件负载集群组。文件共享方案出现瓶颈时，这个时候能够考虑购买昂贵的存储设备 。如NAS等，也可考虑自行设计或是采用成熟的分布式文件系统。

            第九步：数据读写分离与廉价的存储

            如服务器增长太多了，数据库链接至关激烈，读写比至关高，这时可构件大型数据库集群或数据读写分离。数据读写分离可选择的方案或程序级的同步方案，在实现读写分离的时候要同步改造DAL，以适应新的演变。廉价的存储方面有Google的Bigtable、新浪的 Memcachedb等。应具有的知识储备：数据库自行复制、同步方案及实现原理（如Oracle的Standby、MySQL的Replication等）；数据延迟以及不一直的解决方案。读写分离规则判断。

　　　　

 

            第十步：使用反向代理与CDN加速网站响应

　　　　　　

 

　　　第十一步：使用分布式文件系统与分布式数据库

　　　　　　

　　　　第十二步：使用nosql与搜索引擎

　　　　　　

　　　　第十三步：业务拆分　　　　

　　　　　　

　　第十四步：大型分布式应用时代

　　　拆分红分布式后一个很明显的需求就是高效、稳定的通讯和调用框架。

　　　管理好大型分布式的应用，涉及到陆游、以来、版本、错误追踪、检测和报警等多方面的问题。

　　　合理拆分，涉及业务的整理和大型系统架构的把握。

　　　这一步涉及不少知识体系：通讯、分布调用、分布式事务、消息机制、并行计算、报表、检测技术、规则策略等。

　　　　

 

 

二：这个是一个比较经典的框架总结（MVC,RPC,SOA,微服务）

　　在较长的一段时间里，LAMP框架是Web网站的常见方式：Linux+ Apache+ PHP+ MySQL，或者另一套MVC规范，java里比较常见的选择一般是Spring +Struts +MyBatis +Tomcat，有时候也会选择重量级的EJB来实现，尽管在技术细节上的处理各不相同，可是都有一个共性： 垂直应用架构。

　　　　

 

　　1、传统的垂直应用架构

　　1.MVC架构

　　以经典的MVC垂直应用架构为栗子，一般分为三层：

• View展现层，是用户看到并与之交互的界面。
• Control层，用于前端Web请求的分发，调度后台的业务处理。
• Model模型层，包含业务数据和执行逻辑。

　　标准的MVC模式并不包括数据访问层，因此一般还须要专门的ORM框架，能够屏蔽对底层数据库链接池和数据源的实现，提供对上层JDBC的访问，提高开发效率，常见的通常都是Hibernate和Mybatis。一般基于MVC框架的应用都会打成一个war包，部署在Tomcat等Web容器中。

　　业务组网也不复杂，一般作好双热机便可，可经过watchDog来检测应用，判断应用进程是否异常，若是一个出现问题能够当即启动到备机，若是考虑到更复杂的并发场景，可在后端作集群部署，还有前端F5等负载均衡处理。

　　　　

　　

　　2.垂直应用架构的缺陷

1.难以应付复杂的业务场景，且开发和维护的成本会增高。
2.团队协做效率差，公共功能重复开发，重复率高。
3.系统的可靠性变差，某个节点的故障会致使整个系统的“雪崩效应”。
4.维护和定制困难，复杂应用的业务拆分困难，代码修改牵一发而动全身。

　　当垂直应用愈来愈多，应用之间的交互不可避免，将核心业务抽取出来，做为独立的服务，逐渐造成稳定的服务中心，使得前端可以更快的相应市场需求，同时将公共的API抽取出来，能够做为独立的公共服务给其余调用者消费，实现服务的共享和重用，因而有了RPC框架的需求。

　　 2、PRC框架

　　RPC的全称为（Remote Procedure Call），远程过程调用，是一种进程间的通讯方式，在2006年后的移动互联网时代开始兴起，出现了各类各样的开源RPC框架。

　　　　

　　

　　RPC的框架屏蔽了底层的传输方式（TCP/UDP），序列化方式（XML / JASON / ProtoBuf）和通讯细节，使用者只须要知道who（谁）在where（哪里）提供了what（什么）服务便可。

　　一个最简单的RPC框架只须要考虑以下三个部分的实现：

• 服务提供者，运行在服务端，负责提供服务接口定义和实现。
• 服务发布者，运行在RPC服务端，负责将本地服务发布成远程服务，供其余消费者调用；
• 本地服务代理，运行在RPC客户端，经过代理调用远程服务提供者，而后将结果进行封装返回给本地消费者；

　　2.RPC的不足

　　在大规模服务化之前，应用之前只能经过暴露接口和应用远程服务的方式去调用，服务愈来愈多的时候会有如下状况：

• 服务URL的配置管理变的困难
• 服务间的依赖关系变成错综复杂，难以分清哪一个应用要在哪一个应用前启动
• 服务的调用量愈来愈大，服务的容量问题出现问题，某个服务须要多少机器、何时该加机器
• 缺少一个服务注册中心，动态的注册和发现服务。

　　服务化以后，随之而来的就是服务治理问题，如今的RPC框架在这方面都有所欠缺，要解决这些问题必须经过服务框架+服务治理来完成，单凭RPC框架没法解决服务治理的问题。

　　3、SOA服务化架构

　　SOA，Service-Oriented Architecture，面向服务的架构（SOA）是一个组件模型，是一种粗粒度、松耦合的以服务为中心的架构，接口之间经过定义明确的协议和接口进行通讯。
面向服务的核心是对传统的垂直架构进行改造，其中的核心技术就是分布式服务框架，应用也从集中式走向了分布式，大规模系统的架构设计原则就是尽量的拆分，以达到更好的独立扩展与伸缩，更灵活的部署、更好的隔离和容错，更高的开发效率，具体的拆分策略是：横向拆分和纵向拆分。

　　业务纵向拆分：

　　　　根据业务的特性把应用拆开，不一样的业务模块独立部署，将复杂的业务线拆分红相对独立的、灵活的具体能力域，由大到小分而治之。

　　　　　　

 

　　业务横向拆分：

　　　　将核心的、公共的业务拆分出来，经过分布式服务框架对业务进行服务化，消费者经过标准的契约来消费这些服务，服务提供者独立打包、部署，与消费者解耦。

 　　　　

　　服务治理

　　拆分了以后，随着服务数的增多，亟需一个服务治理框架，有效管理服务，提高服务的运行质量，服务治理须要知足：服务生命周期管理，服务容量规划，运行期治理和服务安全等。目前较为成熟的商用服务框架有Spring cloud，阿里巴巴提供的开源的Dubbo框架，非开源的HSF框架，

至于Dubbo和HSF这二者的差异，抄一段来展现：阿里巴巴第一代RPC框架Dubbo是国内第一款成熟的商用级RPC框架，已于2011年正式对外开源，目前已发展成为国内开源价值最高、用户使用规模最大的开源软件之一。2016年度中国开源软件Top10。最新一代RPC框架HSF，全称High Speed Framework，也叫"好舒服"，"很舒服"框架，是阿里内部对这一款高性能服务框架的昵称，是一款面向企业级互联网架构量身定制的分布式服务框架。HSF以高性能网络通讯框架为基础，提供了诸如服务发布与注册，服务调用，服务路由，服务鉴权，服务限流，服务降级和服务调用链路跟踪等一系列久经考验的功能特性。

　　架构原理

　　分布式服务的架构能够抽象为三层：

一、RPC层：底层通讯框架（例如NIO框架的封装），序列化和反序列化框架等。
二、FilterChain层：服务调用职责链，例如负载均衡，服务调用性能统计，服务调用完成通知，失败重发等等。
三、Service层：java动态代理，将服务提供者的接口封装成远程服务调用；java反射，服务提供者使用，根据消费者请求消息中的接口名、方法名、参数列表反射调用服务提供者的接口本地实现类。

　　分布式服务框架的两个核心功能：服务治理和服务注册中心，服务中心中dubbo默认使用的是ZooKeeper，HSF默认使用的为ConfigServer。

　　4、微服务

　　SOA解决了应用服务化的问题，随着服务化实践的深刻，服务的规模也愈来愈大，服务治理的问题也愈来愈多，这时候出现了微服务的思想。微服务架构由多个微小服务构成，每一个服务就是一个独立的可部署单元或组件，它们是分布式的，相互解耦的，经过轻量级远程通讯协议（好比REST）来交互，每一个服务可使用不一样的数据库，并且是语言无关性的。它的特征是彼此独立、微小、轻量、松耦合，又能方便的组合和重构，犹如《超能陆战队》中的微型机器人，个体简单，但组合起来威力强大。

微服务之因此这么火，另外一个缘由是由于 Docker 的出现，它让微服务有一个很是完美的运行环境，Docker 的独立性和细粒度很是匹配微服务的理念，Docker的优秀性能和丰富的管理工具，让你们对微服务有了必定的信息，归纳来讲 Docker 有以下四点适合微服务：

• 独立性：一个容器就是一个完整的执行环境，不依赖外部任何的东西。
• 细粒度：一台物理机器能够同时运行成百上千个容器。其计算粒度足够的小。
• 快速建立和销毁：容器能够在秒级进行建立和销毁，很是适合服务的快速构建和重组。
• 完善的管理工具：数量众多的容器编排管理工具，可以快速的实现服务的组合和调度。

　　做者：YitaiCloud
　　连接：https://www.jianshu.com/p/62398fa9bc64
　　來源：简书
　　简书著做权归做者全部，任何形式的转载都请联系做者得到受权并注明出处。

 

三：阿里Dubbo上总结的一个图

　　展现了的小型网站发展到一个大型网站的过程

　　　　

　　

　　单一应用架构

　　　　当网站流量很小时，只需一个应用，将全部功能都部署在一块儿，以减小部署节点和成本。（减小io的操做，资源的重复利用）
　　　　此时，用于简化增删改查工做量的 数据访问框架(ORM) 是关键。

　　垂直应用架构当访问量逐渐增大，单一应用增长机器带来的加速度愈来愈小，将应用拆成互不相干的几个应用，以提高效率。此时，用于加速前端页面开发的 Web框架(MVC) 是关键。
　　分布式服务架构 
　　　　当垂直应用愈来愈多，应用之间交互不可避免，将核心业务抽取出来，做为独立的服务，逐渐造成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。
　　　　此时，用于提升业务复用及整合的 分布式服务框架(RPC) 是关键。
　　流动计算架构 
　　　　当服务愈来愈多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增长一个调度中心基于访问压力实时管理集群容量，提升集群利用率。
　　　　此时，用于提升机器利用率的 资源调度和治理中心(SOA) 是关键。
　　---------------------
　　做者：行者man
　　来源：CSDN
　　原文：https://blog.csdn.net/it_manman/article/details/79394226?utm_source=copy
　　版权声明：本文为博主原创文章，转载请附上博文连接！

 

四：总结

1.说明

　　上面有三篇文章，第一张是在技术层面的说法，适合帮助理解网站的发展历程，没有明确划分的界限。

　　第二章与第三章是同样：ORM,MVC,RPC,SOA（微服务属于SOA）

 

2.所以

　　对于演变，仍是说明后一种更合适一点。