互联网架构概述
文章目录
互联网架构概述
一、互联网架构特点
二、衡量网站性能的指标
三、互联网架构目标
四、集群和分布式
五、互联网架构演变
1. 单体架构
2. 垂直架构
3. 分布式架构
4. SOA架构
5. 微服务架构

一、互联网架构特点

用户多
流量大，高并发
海量数据
易受攻击
功能繁琐
变更快

二、衡量网站性能的指标

响应时间：发送一个请求到收到响应数据所花费的时间
并发数：系统同时能处理的请求数量
并发连接数：每秒钟服务器的总TCP连接数量
请求数：每秒钟的请求数量
并发用户数：单位时间内的用户数量
吞吐量：单位时间内系统能处理的请求数量

三、互联网架构目标

高性能：提供快速的访问体验
高可用：网站服务一直可以正常访问
可伸缩：通过增加硬件的数量，提高处理能力
高可扩展：系统间耦合度低，方便的增加、移除功能模块
安全性：提供安全的网站访问和数据加密
敏捷性：随需应变，快速响应

四、集群和分布式


集群：多台机器一起做同样的事，即多台服务器的业务模块都相同


分布式：多台机器一起做不同的事，即一个大的业务系统，拆分成多个小的业务模块部署在不同				的服务器上


五、互联网架构演变

1. 单体架构
多个业务模块部署在一台服务器上；功能单一，难以扩展
2. 垂直架构
将单体架构中的多个模块分为多个独立的项目，形成多个单体架构；由于独立，导致每个单体	架构中都需要的相同模块每个单体架构中都需要实现一次，造成重复功能太多
3. 分布式架构
在垂直架构的基础上，将公共的业务模块抽取出来，作为独立的服务供其他调用者共享；底层	通过RPC (远程过程调用)实现
存在的问题：服务提供方一旦产生变更，所有的使用方(消费方)都需要随之变更，比如提供方				  服务器的ip地址产生变化，消费方调用的ip地址也要随之变更
4. SOA架构
使用ESB (企业服务总线)作为消费方和提供方的服务中介；消费方不再和提供方直接交互，通	过总线转发请求，消费方无需知道提供方发生的变化，只需要向总线发出与消费方交互的请求，	由总线找到消费方
5. 微服务架构
基于SOA架构，但更注重对业务的组件化，将原有的业务拆分成多个可以独立开发、运行的小	模块，这些小模块之间进行交互和集成
Dubbo是SOA时代的产物，SpringCloud是微服务时代的产物

互联网架构介绍001 之 单体架构
1. 单体架构
2. 水平架构分层模型图
3. 将同步单体架构修改为异步架构
4. SOA 架构
5. 微服务架构
5.1 微服务架构拆分的本质
5.2 微服务架构适用场景
5.3 微服务架构的目的

互联网架构的演进之路

单体架构 —> 水平分层架构 / 面向服务架构 —> 微服务架构 —> 服务网络架构


1. 单体架构
所有功能模块在同一个Java WAR File 中。





单体架构适用场景

（1）业务场景简单、功能不复杂、研发人员较少，O2O。

（2）适合创业公司初期。

（3）性能要求极其苛刻。


单体架构优点

容易开发布署，测试，开发，扩展。


单体架构缺点

（1）系统耦合性高。

（2）技术选型单一。

（3）开发效率越来越低下。


单体架构模型图如下：



如何破局

（1）数据库存储量大破局思路：

拆分{

      垂直拆分（分库）：当数据量变大时

      水平拆分（分表）： 当数据量变超大时

}

（2）架构同理

垂直方向拆分（业务维度）

水平方向拆分（功能维度）



2. 水平架构分层模型图
将同一个进程拆分为多个进程。




网关开源组件：




3. 将同步单体架构修改为异步架构



4. SOA 架构
多个独立服务，通过 ESB 交互




5. 微服务架构




5.1 微服务架构拆分的本质

两个维度的拆分 （垂直拆分，水平拆分）

相对来说，垂直拆分会更加难一些。
业务架构
组织架构



5.2 微服务架构适用场景

需求层面
性能层面
数据一致性层面



5.3 微服务架构的目的

项目快速迭代
项目持续交付
降人提效（降低人力成本，提高效率）






本文学自视频： https://www.bilibili.com/video/av59516882/?p=3

前言
        互联网时代发展至今，网站架构已经经历了多次的演进，究其原因无外乎以下两点：
        l 用户越来越多，意味着并发要求越来越高
        l 数据越来越多，意味着存储挑战越来越大
 
       在我看来，互联网架构经历了单体架构、水平分层架构、面向服务架构、微服务架构以及服务网格架构等几个不同阶段，每个架构有什么特点？这些架构间有什么不同？让我们一探究竟！
正文
单体架构(MonolithsArchitecture)
        单体架构是指业务功能的实现全部在一个进程（process）内完成。用户请求的接收，相关业务逻辑的调用，从数据库中获取数据等处理全部在一个进程内完成，如图1所示，最终打包成一个WAR包，放入tomcat等web容器里运行。
1     适用场景：
        单体架构适用于哪些场景？
        l 创业初期，人手紧张，又需要快速完成业务需求。
        l 对性能要求极其苛刻场景，哪怕请求慢1ms都无法接受（比如在金融行业，量化交易场景，响应时间就是生命线）。


图1单体架构
 
2     单体架构的优点：
        l 请求响应延迟低，接收客户端请求，经过一次网络交互从数据库批量获取数据，其余的功能全部在进程内完成，避免了多次网络交互。
        l 仅一个进程，部署和运维成本小。
 
3     单体架构的缺点
        l 业务功能单元间耦合严重、扩展性差、技术选型单一（在一个进程内是否可以采用多种开发语言？）等。
        l 单体架构最大的问题是架构粒度过粗，导致系统迭代速度快不起来。互联网业务又是持续高速发展的业务，采用单体架构很难满足需求。
 
        单体架构需要按照某些维度进行拆分：按照系统水平方向进行拆分（水平分层架构）、按照业务功能垂直拆分（SOA架构）、既按照业务功能垂直拆分又按照系统水平方向进行拆分（微服务架构）。
水平分层架构(Horizontallayered Architecture)
        对单体架构在水平方向进行拆分，就会演变成水平分层架构，水平分层架构解决了单体架构存在的高耦合、低扩展性的问题，如图2： 


图2水平分层架构
 
        水平分层架构分为网关层、业务逻辑层、数据访问层以及DB/Cache。每一层都是独立的进程，每个进程职责分明。
1.   分层描述
1.1   网关层
        网关层接收客户端请求，对请求合法性校验以及鉴权、对请求根据URI路由转发到相应的业务逻辑层
1.2   业务逻辑层
        业务逻辑层负责请求具体的业务逻辑处理，在微信端发送消息给好友，业务逻辑层会对发送消息进行黄反等策略检查、会校验发送者的权限（你遇到过“消息已发送，被对方拒收”的情况吗？）、判断接收方是否在线等等。
1.3  数据访问层
        业务逻辑层不会直接和数据库交互，它需要的数据通过数据访问层获取。数据访问层有三部分功能构成：
        l 第一是ORM，接收业务逻辑层发送的数据协议（JSON等文本协议或者PB等二进制协议）转换成SQL协议；
        l 第二是Sharding，数据库存储数据超过千万级别时，为了进一步提升性能，会按照业务功能垂直拆分库以及水平方向拆分表。因此在此层提供分库分表支持，对业务逻辑层透明，使之无感知。
        l 第三是随着业务请求量继续增大，Sharding后依然无法满足性能需求，进一步增加Cache功能，对业务逻辑层透明。存储层往往使用MySQL提供关系存储，使用Redis提供缓存。
 
        大家熟知的MVC架构，本质上是水平分层架构，分为Model层、View层、Control层。水平分层架构分层不易过多，每增加一层，请求响应延迟相应会增加；分层越多，定位线上问题难度越大。根据业务使用场景的不同，常常对水平分层架构分为三层（MVC）、四层（图2）、五层（图3）。
 
2.   异步化水平分层



图3异步化水平分层架构
 
        图3和图2相比，增加MQ层（消息队列层），APP端更新请求经过网关层后持久化到MQ层，返回给APP端。业务逻辑层从MQ层读取更新请求消费。在架构上，通过MQ层把更新请求的处理进行了异步化。图3即变成了异步化水平分层架构。采用异步化水平分层架构，提升了系统整体吞吐量。在社区等高并发业务场景适合异步化架构。异步化架构会带来数据处理的延迟情况，因此对数据一致性要求苛刻的业务场景，比如金融、支付等，异步化架构不适合，这些场景常使用图2同步水平分层架构。
        水平分层架构解决了单体架构的问题，它存在的明显问题是每层粒度过粗，在每一层并没有按照业务功能单元进一步垂直拆分。
 
面向服务化架构(SOAArchitecture)
        单体架构按照业务功能在垂直方向进行拆分，就变成了SOA架构，如图4:


图4 SOA架构
 
        图4按照业务功能单元进行拆分，分为了交互服务、信息服务等，每一个服务都是单体，单体服务之间通过企业服务总线（ESB）进行交互。可知SOA架构仅进行了垂直方向拆分，对每个服务并没有按照水平方向进一步拆分，因此SOA架构拆分也不彻底。
        SOA的提出是在企业计算领域，就是要将紧耦合的系统，划分为面向业务的，粗粒度，松耦合，无状态的服务。服务发布出来供其他服务调用，一组互相依赖的服务就构成了SOA架构下的系统。
        基于这些基础的服务，可以将业务过程用类似BPEL流程的方式编排起来，而BPEL反映的是业务处理的过程，这些过程对于业务人员更为直观，调整也比hardcode的代码更容易。
         当然企业还需要对服务治理，比如服务注册库，监控管理等。
         我们知道企业计算领域，如果不是交易系统的话，并发量都不是很大的，所以大多数情况下，一台服务器就容纳将许许多多的服务，这些服务采用统一的基础设施，可能都运行在一个应用服务器的进程中。虽然说是面向服务了，但还是单一的系统。
微服务架构(MicroServicesArchitecture)
        服务架构的出现，解决了水平分层架构以及SOA架构拆分不彻底的问题。微服务架构是Martin Fowler 在2014年提出的架构模式（如图5）。


图5 微服务定义
 
        微服务首先按照业务领域模型垂直拆分，即根据不同的业务功能单元进行垂直拆分。对垂直拆分后的服务，在水平方向继续进行拆分。
1.   特点
        微服务架构有如下特点：按照业务领域拆分服务、一系列小服务构成、服务独立部署、独立运行、服务间去中心化管理（任何一个服务都可以采用任何开发语言 C/PHP/Go/Java等，也可以运行于任何的平台Linux/Windows等）。
2.   例子
        二手交易平台转转，包括了用户功能、商品功能、交易功能、搜索功能以及推荐功能。各个业务单元相对独立，首先按照业务垂直拆分成用户、商品、交易、搜索、推荐微服务。对每一个功能单元（商品等），继续进行水平拆分，分为商品网关层、商品业务逻辑层、商品数据访问层、商品DB/Cache，对用户、交易、搜索、推荐等业务同样方式进行水平拆分，最终微服务架构如图6:


图6 微服务架构
3.  微服务架构组成元素
        那么典型的微服务架构由哪些元素组成呢？如图6，包括网关、微服务业务逻辑层（聚合层）、数据访问层（原子层）、数据存储、注册中心、配置中心。网关负责请求接入，聚合层用于各种业务逻辑的处理，数据原子层用做数据访问代理，提供ORM、数据Sharding以及屏蔽底层存储的差异性等功能。
因此，从业务角度看，微服务架构本质上是一个业务架构，对业务了解越深刻，微服务拆分越合理；从系统角度看，微服务架构是水平分层架构和SOA架构的结合体。
4.  为服务架构的缺点
        采用微服务架构后，一方面请求链条变长，对请求响应要求苛刻的场景不适合微服务架构；另一方面服务变多，实施数据一致性的难度变大，对数据要求强一致性的场合也不适合使用微服务架构。
        采用微服务架构后，项目能够做到快速迭代，持续交付。微服务架构也存在明显的弊端：开发人员除了关注业务逻辑的实现外，还需要在微服务模块里处理一系列问题，比如服务注册、服务发现、服务通讯、负载均衡、服务熔断、请求超时重试等，这是非常糟糕的。业务开发团队的强项在于业务理解，而不是技术。
        能否让业务开发人员仅关注业务开发，服务间通讯以及请求管理功能不再关心？服务网格架构解决了这个问题，让业务开发人员真正解脱。
 
服务网格架构(ServiceMesh Architecture)
1.   定义
        服务网格由Buoyant公司提出，2017年初Buoyant公司CEO William Morgan给出服务网格的定义如下 （图7）：


图7服务网格定义
 
        如果用一句话来解释什么是服务网格，可以将它比作是应用程序或者说微服务间的TCP/IP，负责服务之间的网络调用、限流、熔断和监控。对于编写应用程序来说一般无须关心 TCP/IP 这一层（比如通过 HTTP 协议的 RESTful 应用），同样使用服务网格也就无须关系服务之间的那些原来是通过应用程序或者其他框架实现的事情，比如 Spring Cloud、OSS，现在只要交给 Service Mesh 就可以了。
        服务网格是一个基础设施层，用于处理服务间通信。对于有着复杂拓扑结构的云原生服务，服务网格负责实现这些服务间请求的可靠传递。在实践中，服务网格通常实现为一组轻量级网络代理，它们与应用程序部署在一起，并对应用程序透明。
2.   特点
        Service mesh有如下几个特点
        l 应用程序间通讯的中间层
        l 轻量级网络代理
        l 应用程序无感知
        l 解耦应用程序的重试/超时、监控、追踪和服务发现
3.   理解服务网格
        我们来看一个例子，如图8:


图8 服务网格例子
 
        一个应用请求首先发送给远程的服务网格实例，服务网格完成服务发现、服务通讯、负载均衡等完整调用流程，最后将请求发送给目标服务。
        继续来看一下服务网格的架构，如图9:
 
图9 服务网格架构
 
        服务网格作为 sidecar 运行，对应用程序来说是透明，所有应用程序间的流量都会通过它，所以对应用程序流量的控制都可以在服务网格中实现。
        因此服务网格是一个基础设施层，独立于服务之外，对服务透明，实现了请求的可靠传递。有了服务网格，业务开发人员再也不用关注服务发现、负载均衡、服务重试、熔断等，可以专注在业务开发上。
4.  未来
        开源的服务网格产品陆续发布出来：来自Buoyant公司的Linkerd、来自Lyft公司的Envoy、来自nginx的nginmesh以及来自Google/IBM/Lyft公司的Istio等。最值得关注的当数Isto，出身名门，王者风范，期待Istio像k8s一样成为现象级的重量产品。
        无服务器(Serverless)计算（如Amazon的Lambda）正好需要Service Mesh的命名和链接模型，这让Service Mesh在云原生生态系统中的角色得到了彰显。服务识别和访问策略在云原生环境中仍显初级，而Service Mesh毫无疑问将成为这方面不可或缺的基础。就像TCP/IP一样，Service Mesh将在底层基础设施这条道上更进一步。
        服务网格这个词仅出现一年的时间，服务网格产品实施落地还需要一些时间，期待后续继续完善，使业务开发同学能够真正回归业务开发本身。
总结
        互联网架构的演进，看似简单，但这其中凝聚了无数IT人的努力和智慧。不断增长的业务需求是技术发展的动力，期待将来会有更多更好的互联网架构诞生。
 

转自：http://www.cnblogs.com/wuyuankun/p/3984209.html

主流互联网架构




基础知识点：
Squid：
Squid cache（简称为Squid）是一个流行的自由软件，它符合GNU通用公共许可证。Squid作为网页服务器的前置cache服务器，可以代理用户向web服务器请求数据并进行缓存，也可以用在局域网中，使局域网用户通过代理上网。Squid主要设计用于在Linux一类系统运行。
 
Memcached ：
Memcached 是一个高性能的分布式内存对象缓存系统，用于动态Web应用以减轻数据库负载。它通过在内存中缓存数据和对象来减少读取数据库的次数，从而提高动态、数据库驱动网站的速度。Memcached基于一个存储键/值对的hashmap。其守护进程（daemon
 ）是用C写的，但是客户端可以用任何语言来编写，并通过memcached协议与守护进程通信。
ESI 动态缓存技术：
任何一个Web网站的内容都是在不断更新和变化，但这并不意味这这个网站的内容就是动态内容，事实上，动态的内容是指用户每次点击 相同的链接时取的的内容是由Web服务器应用程序生成的，如常见得ASP，JSP等，与此相对应，静态内容一般就是指由文本、图像和多媒体组成，在用户每 次单击相应链接时基本保持不变。现在解决动态内容缓存的最新技术就是通过ESI技术来设计网站的内容。
    ESI技术工作原理
    动态生成的内容能为用户带来丰富精彩的页面，网站开发者也可以更容易和更灵活地控制相关的内容，但在享受这些便利的同时，也增加了 网站数据库和应用服务器的处理压力的。当网站的访问量增大后，硬件和数据库的投资是非常巨大的，即使如此，仍然有可能导致页面的严重延迟甚至访问失败。
    用户访问动态生成的内容速度慢的根本原因在于动态生成的内容需要经过一个复杂的过程，首先，根据用户请求的不同将用户的请求分配 到应用服务器相应的软件模块中，软件模块必须通过运算决定需要从数据库中提取什么样的数据给用户，然后再从数据库中提取出相应的数据按照定义的格式传给用 户。这些冗长的过程导致用户访问速度变慢，同时增加了服务器的负载。
    在实际环境中，一个动态生成的页面，当中可能只有少量的内容是频繁变化的或是个性化的，对于传统的Cache服务器来说，为了能 够保证页面的时效性，却由于页面中这些少量的动态内容而无法将整个页面进行缓存。ESI（Edge Side Include）通过使用简单的标记语言来对那些可以加速和不能加速的网页中的内容片断进行描述，每个网页都被划分成不同的小部分分别赋予不同的缓存控制 策略，使Cache服务器可以根据这些策略在将完整的网页发送给用户之前将不同的小部分动态地组合在一起。通过这种控制，可以有效地减少从服务器抓取整个
 页面的次数，而只用从原服务器中提取少量的不能缓存的片断，因此可以有效降低原服务器的负载，同时提高用户访问的响应时间。
    ESI是一种简单的标识语言，开发人员可以使用它标志内容片断以便通过相应的Cache服务器来加速缓存。同时ESI还定义了一 套内容效验标准，可以实现原服务器对Cache服务器中缓存内容的管理，提高了网站对内容的控制能力。CDN网络也可以利用在分布全国各地的节点中安装支 持ESI的Cache服务器来提供对网站动态内容提供CDN服务
 
****************************************************************************************************************************
 

第一步：物理分离webserver和数据库
刚开始我们的网站可能搭建在一台服务器上，这个时候由于网站具备了一定的特色，吸引了部分人访问，逐渐你发现系统的压力越来越高，响应速度越来越慢，而这个时候比较明显的是数据库和应用互相影响，应用出问题了，数据库也很容易出现问题，而数据库出问题的时候，应用也容易出问题，于是进入了第一步演变阶段：将应用和数据库从物理上分离，变成了两台机器，这个时候技术上没有什么新的要求，但你发现确实起到效果了，系统又恢复到以前的响应速度了，并且支撑住了更高的流量，并且不会因为数据库和应用形成互相的影响。

图3.1
3.2第二步：增加页面缓存
好景不长，随着访问的人越来越多，你发现响应速度又开始变慢了，查找原因，发现是访问数据库的操作太多，导致数据连接竞争激烈，所以响应变慢，但数据库连接又不能开太多，否则数据库机器压力会很高，因此考虑采用缓存机制来减少数据库连接资源的竞争和对数据库读的压力，这个时候首先也许会选择采用squid等类似的机制来将系统中相对静态的页面（例如一两天才会有更新的页面）进行缓存（当然，也可以采用将页面静态化的方案），这样程序上可以不做修改，就能够很好的减少对webserver的压力以及减少数据库连接资源的竞争，OK，于是开始采用squid来做相对静态的页面的缓存。

图3.2
3.3第三步：增加页面片段缓存
增加了squid做缓存后，整体系统的速度确实是提升了，webserver的压力也开始下降了，但随着访问量的增加，发现系统又开始变的有些慢了，在尝到了squid之类的动态缓存带来的好处后，开始想能不能让现在那些动态页面里相对静态的部分也缓存起来呢，因此考虑采用类似ESI之类的页面片段缓存策略，OK，于是开始采用ESI来做动态页面中相对静态的片段部分的缓存。

图3.3
3.4第四步：数据缓存
在采用ESI之类的技术再次提高了系统的缓存效果后，系统的压力确实进一步降低了，但同样，随着访问量的增加，系统还是开始变慢，经过查找，可能会发现系统中存在一些重复获取数据信息的地方，像获取用户信息等，这个时候开始考虑是不是可以将这些数据信息也缓存起来呢，于是将这些数据缓存到本地内存，改变完毕后，完全符合预期，系统的响应速度又恢复了，数据库的压力也再度降低了不少。可以使用的技术有：memcached。

图3.4
3.5第五步：增加webserver
好景不长，发现随着系统访问量的再度增加，webserver机器的压力在高峰期会上升到比较高，这个时候开始考虑增加一台webserver，这也是为了同时解决可用性的问题，避免单台的webserver down机的话就没法使用了，在做了这些考虑后，决定增加一台webserver，增加一台webserver时，会碰到一些问题，典型的有：
1、如何让访问分配到这两台机器上，这个时候通常会考虑的方案是Apache自带的负载均衡方案，或LVS这类的软件负载均衡方案；
2、如何保持状态信息的同步，例如用户session等，这个时候会考虑的方案有写入数据库、写入存储、cookie或同步session信息等机制等；
3、如何保持数据缓存信息的同步，例如之前缓存的用户数据等，这个时候通常会考虑的机制有缓存同步或分布式缓存；
4、如何让上传文件这些类似的功能继续正常，这个时候通常会考虑的机制是使用共享文件系统或存储等；
在解决了这些问题后，终于是把webserver增加为了两台，系统终于是又恢复到了以往的速度。

图3.5
3.6第六步：分库
享受了一段时间的系统访问量高速增长的幸福后，发现系统又开始变慢了，这次又是什么状况呢，经过查找，发现数据库写入、更新的这些操作的部分数据库连接的资源竞争非常激烈，导致了系统变慢，这下怎么办呢，此时可选的方案有数据库集群和分库策略，集群方面像有些数据库支持的并不是很好，因此分库会成为比较普遍的策略，分库也就意味着要对原有程序进行修改，一通修改实现分库后，不错，目标达到了，系统恢复甚至速度比以前还快了。

图3.6
3.7第七步：分表、DAL和分布式缓存
随着系统的不断运行，数据量开始大幅度增长，这个时候发现分库后查询仍然会有些慢，于是按照分库的思想开始做分表的工作，当然，这不可避免的会需要对程序进行一些修改，也许在这个时候就会发现应用自己要关心分库分表的规则等，还是有些复杂的，于是萌生能否增加一个通用的框架来实现分库分表的数据访问，这个在ebay的架构中对应的就是DAL，这个演变的过程相对而言需要花费较长的时间，当然，也有可能这个通用的框架会等到分表做完后才开始做，同时，在这个阶段可能会发现之前的缓存同步方案出现问题，因为数据量太大，导致现在不太可能将缓存存在本地，然后同步的方式，需要采用分布式缓存方案了，于是，又是一通考察和折磨，终于是将大量的数据缓存转移到分布式缓存上了。

图3.7
3.8第八步：增加更多的webserver
在做完分库分表这些工作后，数据库上的压力已经降到比较低了，又开始过着每天看着访问量暴增的幸福生活了，突然有一天，发现系统的访问又开始有变慢的趋势了，这个时候首先查看数据库，压力一切正常，之后查看webserver，发现apache阻塞了很多的请求，而应用服务器对每个请求也是比较快的，看来是请求数太高导致需要排队等待，响应速度变慢，这还好办，一般来说，这个时候也会有些钱了，于是添加一些webserver服务器，在这个添加webserver服务器的过程，有可能会出现几种挑战：
1、Apache的软负载或LVS软负载等无法承担巨大的web访问量（请求连接数、网络流量等）的调度了，这个时候如果经费允许的话，会采取的方案是购买硬件负载，例如F5、Netsclar、Athelon之类的，如经费不允许的话，会采取的方案是将应用从逻辑上做一定的分类，然后分散到不同的软负载集群中；
2、原有的一些状态信息同步、文件共享等方案可能会出现瓶颈，需要进行改进，也许这个时候会根据情况编写符合网站业务需求的分布式文件系统等；
在做完这些工作后，开始进入一个看似完美的无限伸缩的时代，当网站流量增加时，应对的解决方案就是不断的添加webserver。

图3.8
3.9第九步：数据读写分离和廉价存储方案
突然有一天，发现这个完美的时代也要结束了，数据库的噩梦又一次出现在眼前了，由于添加的webserver太多了，导致数据库连接的资源还是不够用，而这个时候又已经分库分表了，开始分析数据库的压力状况，可能会发现数据库的读写比很高，这个时候通常会想到数据读写分离的方案，当然，这个方案要实现并不容易，另外，可能会发现一些数据存储在数据库上有些浪费，或者说过于占用数据库资源，因此在这个阶段可能会形成的架构演变是实现数据读写分离，同时编写一些更为廉价的存储方案，例如BigTable这种。

图3.9
3.10第十步：进入大型分布式应用时代和廉价服务器群梦想时代
经过上面这个漫长而痛苦的过程，终于是再度迎来了完美的时代，不断的增加webserver就可以支撑越来越高的访问量了，对于大型网站而言，人气的重要毋庸置疑，随着人气的越来越高，各种各样的功能需求也开始爆发性的增长，这个时候突然发现，原来部署在webserver上的那个web应用已经非常庞大了，当多个团队都开始对其进行改动时，可真是相当的不方便，复用性也相当糟糕，基本是每个团队都做了或多或少重复的事情，而且部署和维护也是相当的麻烦，因为庞大的应用包在N台机器上复制、启动都需要耗费不少的时间，出问题的时候也不是很好查，另外一个更糟糕的状况是很有可能会出现某个应用上的bug就导致了全站都不可用，还有其他的像调优不好操作（因为机器上部署的应用什么都要做，根本就无法进行针对性的调优）等因素，根据这样的分析，开始痛下决心，将系统根据职责进行拆分，于是一个大型的分布式应用就诞生了，通常，这个步骤需要耗费相当长的时间，因为会碰到很多的挑战：
1、拆成分布式后需要提供一个高性能、稳定的通信框架，并且需要支持多种不同的通信和远程调用方式；
2、将一个庞大的应用拆分需要耗费很长的时间，需要进行业务的整理和系统依赖关系的控制等；
3、如何运维（依赖管理、运行状况管理、错误追踪、调优、监控和报警等）好这个庞大的分布式应用。
经过这一步，差不多系统的架构进入相对稳定的阶段，同时也能开始采用大量的廉价机器来支撑着巨大的访问量和数据量，结合这套架构以及这么多次演变过程吸取的经验来采用其他各种各样的方法来支撑着越来越高的访问量。

图3.10
4.分析
随着平台做大做强，很可能会走向定制操作系统，定制数据库，甚至定制硬件，定制任何可以定制的东西这样一条路。
在服务器、架构、组件等技术选择方面，主要有两个方向：1选择成熟商用。2选择开源+自主研发。下面就这两个方向逐一进行简单分析。
1商用的优缺点
l 商用的优点之一是成熟，稳定，搭建快速。
l 商用的缺点之一是费用高，随着服务器的增加，license的费用上升，成本偏高。
l 商用的产品是通用化的，缺乏定制性，不能满足个性需要。
2开源+自主研发的优缺点
l 源码开放，可控性好，出现问题，可以从底层解决，扩展性好。
l 短期时间、人力投入大，初期见效慢；长期产出大，见效明显。
l 可以在软件和硬件的多个层面不断优化，充分满足个性化需要。
商用和开源+自主研发各有优缺点，各有互补性，要根据使用场景的不同来进行选择，也可以根据需要配合使用。
5.总结
目前大型网站的主流是LAMP（linux+apache+mysql+php），或者是在这基础之上的扩展，例如增加缓存，增加中间件（中间件大多使用java，c，c++或者.NET编写，或者购买成熟的中间件产品，IBM就有很多成熟的中间件产品）；又或者替换其中的某些部分，例如前端使用python，ruby，lua这些新近流行的脚本语言，数据存储部分使用nosql或者文件系统。这样的选择有历史原因、费用原因、业务原因，也有在网站发展之后需要满足新的需求而衍生出来解决特定问题的原因。
也有初期使用微软系（windows+.NET+MSSQL）来构建网站的，在后面又根据需要加入其他体系的的电商，例如：京东，当当，凡客等。也有始终采用微软系的网站，国外的微软官网，stackoverflow，还有曾经辉煌的myspace。
其实，现在的发展趋势是：混合体系，而非单一的体系。就是说技术体系不是单一的，也不是固定一成不变的，而是根据业务以及网站的发展，以及技术的发展，选择合适的技术解决适当的问题。
架构的变更不是一件小事，对业务和网站的发展都很重要，不可能几天或者一半个月就变更一下，也不可能有事没事变更一下，应该是在关键的时候，有需要的时候，或者根据计划定期升级。
我觉得有一种方式可以帮助我们进行选择。就是根据我们的目标，或者说预估的业务量，预估的成交量，预估的用户量，划分几个平台发展里程碑，或者是时间段。然后根据平台发展的里程碑来规划技术选型的里程碑。考虑规模的同时，还需要考虑业务的类型，产生的数据的类型，对这些数据的处理需求等因素。
可以先定几个里程碑，这个里程碑的时间，可以根据前面的业务预估来裁定。先根据第一个里程碑要满足的业务需求，来选择当前的技术架构，并且进行存储空间规划。然后针对第一个到第二个里程碑的过度，进行预留设计，保证将来的平稳过渡。或者只是预留扩展的余地，这方面有时候有点难度，不过应该尽量做。
在第二个里程碑之前的1-2个月进行第二个里程碑技术架构的讨论和设计，因为这时候相比原有的第二个里程碑的业务估计可能会有变动，或者技术上有了新的选择，都可以及时考虑到本次的设计中来。以此类推后面的里程碑技术架构变更。
还有就是突发情况，因为总会有一些意料之外的情况发生，有的是业务发展的需要，有的是被动的需要。针对这些突发情况，也会进行架构的升级。
 
****************************************************************************************************************************
 

             较为完整的系统架构图
2.系统使用的主要技术
下列排名不分先后
2.1前端
JavaScript，html，css，silverlight，flash
Jquery
Javascript类库，用来简化html的操作，事件处理，动画，异步访问，用于web的快速开发。最新版本是1.7.1，分为开发环境（大小为229k）和生产环境（大小为31k）。特点是轻量，体积小；css兼容1-3；跨浏览器。凡客，当当，亚马逊。
如果从框架角度分级的话，可以有以下分类：
零级，完成base工作，包括扩展原有对象的方法，Ajax通讯部分，比较精简
一级，完成effect工作，包括增加常用效果转换函数，如tween、drag、maskLayer、fade等的特效
二级，完成component工作，包括对话框、列表、树、日历等的组件
三级，完成application工作，包括完整的前端平台，允许用户定义能实现一定功能的模块
一些UI控件和开发框架只做零级Prototype.js，和一级jQuery/Mootools；一些做到了三级，如Dojo和EXT。
Kissky
小巧灵活，简洁实用，使用起来让人感觉愉悦。淘宝，腾讯。
2.2后端
Php，Perl，asp，ruby，python，.net，java，jsp（java server page）
静态语言：java, .net
动态语言（脚本语言）：php, asp, jsp, perl, python, ruby
Php是老牌的脚本语言，尽管出现了很多的新语言，但是php还是大多数网站的首选，据说全世界70%的网站都使用php。LAMP(linux+apache+mysql+php)是经典组合。
ASP是Active Server Page的缩写，意为“动态服务器页面”。ASP是微软公司开发的代替CGI脚本程序的一种应用，它可以与数据库和其它程序进行交互，是一种简单、方便的编程工具。ASP的网页文件的格式是。常用于各种动态网站中。
JSP（Java Server Pages)是由Sun Microsystems公司倡导、许多公司参与一起建立的一种动态网页技术标准。JSP技术有点类似ASP技术，它是在传统的网页HTML文件(*.htm,*.html)中插入Java程序段(Scriptlet)和JSP标记(tag)，从而形成JSP文件(*.jsp)。
 用JSP开发的Web应用是跨平台的，既能在Linux下运行，也能在其他操作系统上运行。
Python和ruby是近几年崛起的开源语言，特点是容易上手，能快速完成原型。同时也是较为成熟脚本语言。Python是豆瓣的主要语言，google，youtube等网站也都在使用。
http://www.python.org/about/quotes/
Twitter的前端主要使用ruby，motorola和NASA也都使用了ruby。
http://www.ruby-lang.org/en/documentation/success-stories
2.3缓存
•Squid cache
开源。
Squid服务器群，把它作为web服务器端的前置cache服务器，缓存相关请求来提高web服务器速度。Squid将大部分静态资源(图片，js，css等）缓存起来，也可以缓存频繁访问的网页，直接返回给访问者，减少应用服务器的负载。
•memcached
开源。
Wikipedia，Flickr，Twitter，Youtube
memcached服务器群，一款分布式缓存产品，很多大型网站在应用; 它可以应对任意多个连接，使用非阻塞的网络IO。由于它的工作机制是在内存中开辟一块空间，然后建立一个HashTable，Memcached自管理这些HashTable。因为通常网站应用程序中最耗费时间的任务是数据在数据库的检索，而多个用户查询相同的SQL时，数据库压力会增大，而通过memcached的查询缓存命中，数据直接从memcached内存中取，每次缓存命中将替换到数据库服务器的一次往返，到达数据库服务器的请求更少，间接地提高了数据库服务器的性能，从而使应用程序运行得更快。它通过基于内存缓存对象来减少数据库查询的方式改善网站系统的反应，其最吸引人的一个特性就是支持分布式部署。
2.4中间件
Java，.net，c，c++
2.5存储
2.5.1关系数据库
Oracle，mysql，mssql，postgreSQL
postgreSQL
关系数据库，拥有15年的历史。免费，开源。可以运行在linux、unix和windows上，支持事物、主外键、连接、视图、触发器、存储过程。包含大量的数据类型，也支持大对象。支持多种语言，c，c++，java，c#，perl，python，ruby等等。
2.5.2 NoSQL存储
MongoDB，Redis，CouchDB，Cassandra，HBase
NoSQL(not only sql)，不仅仅是SQL。用来弥补关系数据库在某些方面的不足。例如：
l 高并发读写。每秒上万次的读写，关系数据库有点吃力。
l 海量数据的高效存储和访问。例如：对一张表有2亿数据的表进行读写，效率较为低下。
l 高扩展性。对于数据库的升级和扩展，增加节点，往往需要停机和数据迁移。
有一些地方不需要关系数据库，例如：
l 事务一致性。某些场合不需要事务，对于数据的一致性也没有严格要求。
l 读写实时性。有些场合不需要实时的读写。
http://baike.baidu.com/view/2677528.htm
Mongodb
文档型nosql，支持主从复制。有很多的大公司使用。支持多种编程语言。
http://www.mongodb.org/display/DOCS/Production+Deployments
Disney，SAP，淘宝（监控数据），sourceforge，大众点评（用户行为分析，用户、组）。
Redis
键值型nosql，vmware赞助，支持多种编程语言。Twitter，淘宝，新浪微博都有使用。
Couchdb，cassandra，hbase
都是apache旗下的项目。
2.5.3文件系统
商用中间件，自定义文件系统
2.6操作系统
Windows，linux，unix
2.7 Web应用服务器软件
IIS，apache，tomcat，jboss，weblogic（BEA，商用，收费），websphere（IBM，商用，收费），lighttpd，nginx
IIS
微软windows操作系统专用。
Lighttpd
lighttpd，是一个德国人领导的开源软件，其根本的目的是提供一个专门针对高性能网站，安全、快速、兼容性好。lighttpd并且灵活的web server环境。具有非常低的内存开销，cpu占用率低，效能好，以及丰富的模块等特点。lighttpd是众多OpenSource轻量级的web server中较为优秀的一个。支持FastCGI, CGI, Auth, 输出压缩(output
 compress), URL重写, Alias等重要功能，
Nginx
开源
Nginx+php（FastCGI）+Memcached+Mysql+APC 是目前主流的高性能服务器搭建方式！适合大中型网站，小型站长也可以采用这种组合！
Nginx 超越 Apache 的高性能和稳定性，使得国内使用 Nginx 作为 Web 服务器的网站也越来越多，其中包括国内最大的电子地图MapBar、新浪博客、新浪播客、网易新闻等门户网站频道，六间房、56.com等视频分享网 站，Discuz！官方论坛、水木社区等知名论坛，豆瓣、YUPOO相册、海内SNS、迅雷在线等新兴Web 2.0网站，更多的网站都在使用Nginx配置。
2.8 框架
Javascript：Jquery，prototype.js，Kissky，extjs。
.NET：企业库，unity，NHibernate，Sprint.NET，ibatis，MVC，MEF，Prism，log4net，23个开源项目，lucene.NET
Java：hibernate，spring，struts，easyjf，log4j，开源项目，lucene
Python：django，flask，bottle，tornado，uliweb，web.py
Ruby：rails
PHP：PEA