网站架构演变过程-------从传统项目到分布式项目再到微服务

CDSY,CDSY.XYZ

网站架构演变过程

传统项目（单点应用）----》分布式架构 （以项目进行拆分）----》SOA架构（面向服务架构）----》微服务架构

传统项目的架构：

传统项目框架其实就是SSH或SSM,属于单点应用，把整个业务模块，都放在一个项目当中进行开发，分为MVC框架，会拆分为控制层Controller，业务逻辑层Service，数据库服务层Dao

特点：

• all in one(所有模块在一起，技术也不分层)，
  注：像05年06年那会儿，就是这样，把代码写在jsp里面，那时候还没有分层的概念，把所有的东西都写在一起，这就叫做all in one
• servlet(jsp)
• 项目部署起来非常简单，就需要打成一个war包。
• 一般是适合于个人或者是小团队开发。

缺点：

• 并发量差
• 这种架构模式耦合度高，一旦有一个模块导致服务不可用，可能会影响整个项目。
• 容错性差(不具有高可用性)
  注：不具有高可用性的意思是，比如当用户访问时，服务器后台因为一些原因导致服务器崩溃，用户就能直接看到错误页面，服务器也因为错误从而停止运行(宕机)，这就叫做不具有高可用性。

解决方案：

1.分层开发(可以提高并发量)

2.mvc架构

3.服务器的分离部署

=========================================================

mvc架构：

集群架构（搭建集群的方式不可取，因为成本太高）

特点：

1.项目采用多台服务器集群部署

2.mysql数据库采用多台服务器集群部署

优势：

1.并发量提高(1000+)

2.容错性提高(具有高可用性)

注：一般的it公司，基本都是采用集群架构，因为这种架构方式已经基本能满足需求了，但是一些大型项目，这种方式就显然是力不从心了，只能采用分布式的架构方式。

但是，通过上图我们发现这种集群部署存在两个问题，什么问题呢？

1.session如何共享？

2.这么多服务器，请求该往哪发送？

下面咱们就针对这两个问题一一解答：

　首先第一个问题，session的问题：

　

我们都知道，session是会话，即一个用户访问服务器的时候，就会产生一个session，这个session会一致伴随着这个用户的访问全程，直到用户关闭浏览器结束这次会话，那么问题来了，问，挖掘技术哪家强？咳咳，错了，是如果用户访问服务器时，这台服务器挂掉了(宕机)，那么原先保存在这台服务器上的session也肯定挂掉了，那么就会产生一个后果，就是这个用户原本访问好好的，现在突然session没有了，而session没有了就意味着需要用户重新登陆才能进行一些相应操作，这显然是不行的，这样的服务用户体验实在太差了，根本不能满足互联网行业的用户需求，那么这就涉及到一个session共享的问题，即怎么把原有的session从一台服务器转移到另一台服务器上，但是怎么解决呢？有多种方案，但咱们今天先说两种：

第一种解决方案：

　用Tomcat集群复制(广播模式)来共享session：

　这种解决方案是利用Tomcat来进行集群复制，把每个服务器上的session都共享式的都复制一遍，保证每个服务器上都有着一个用户的session数据

应用场景：在传统项目中一般这么应用，因为传统项目的用户量少，可以承担压力，但当到互联网项目时，这种方式就绝对不可取了，打个比方，比如用户量有100万，那么就需要在每个服务器上都复制这100万个用户的session，这样做显然会极大的消耗系统资源，使系统变得极为臃肿和不稳的，所以在互联网项目里是绝对不会采用这种方式的

缺点：当有大量用户时，服务器的压力会亚历山大，所以只适合用户访问量小的传统项目

第二种解决方案：

用第三方redis服务器来存储session：

用这种方式来存储session的话，只需当前正在使用的项目把所有session都放在redis里面，当有其他项目需要使用时，就可以直接从redis中直接获取session，从而解决了这个问题。

示例如图：

现在第一个问题解决了，我们来考虑第二个问题，怎么解决选择哪个作为解释请求的服务器呢？

答案是：用nginx服务器来分发请求，实现负载均衡。

这种架构的并发量是多少呢？大概是1000+左右，如果服务器更多的话，能达到1000以上，一万以下，但是这能满足互联网的极致要求呢？

答案当然是不能了，虽说也可以不断的扩展服务器，但是对于公司的成本和维护成本来说，无疑会达到一个非常高昂的消耗，比如说一台最便宜的服务器的价格大概是3到5万，假如要抵御一万的并发，每台服务器能支持200的并发率，那么需要多少台服务器？50台！这还仅是单击版的，还构建集群呢？比如说构建3台服务器，3*50=150台，服务器构建完了，数据库呢？数据库也需要构建集群呀！，这就又是好几百台，这么一算下来大概的费用就是好几百万了，这仅仅是配置的费用，还没有计算维护的成本呢？

比如说我们都知道服务器对于机房的要求是非常苛刻的，比如恒温，无尘等等(题外话：阿里之所以把云计算基地定在杭州就是看中了那里气温稳定，适合布置服务器集群)。这样一来又需要布置大型的机房。

综合以上所述，虽说集群能后解决部分问题，但并不能解决所有问题，无论是从公司成本还是运营成本来说，显然这种传统的集群架构是不适应现在的互联网行业的，而且对于一般的公司来说也不可能去花大价钱做这种布置。

所以，这种情况下我们就必须对我们的架构来进行优化了，那么如何在服务器只有一定数量的情况下，让我们的项目的成本能达到一定控制，并且让我们的项目达到一个最优化的并发的访问量呢？那么就需要对现有的这种架构进行再次拆分，让我们的项目成为面向服务的分布式架构。

面向服务的SOA架构

SOA架构代表面向与服务架构，俗称服务化，通俗的理解为面向与业务逻辑层开发，将共同的业务逻辑抽取出来形成一个服务，提供给其他服务接口进行调用，服务与服务之间调用使用rpc远程技术。

SOA架构特征：将共用的代码抽取出来，提供一个对外的接口，提供给其他服务进行调用，这样就能减少重复代码，比如会员后台项目，需要进行用户查询，会员前台项目也要进行用户查询，他们完全可以使用一套业务逻辑层，只有包装Controller层不一样即可。

如图所示，第一种方式还是有着明显的缺点的，如服务层的网路抖动或是服务层进程繁忙，可能有人对这两个名词不太理解，这里就解释一下：

- 网络抖动：

当有大量用户访问时，可能会出现service层的延迟现象，而web层因为长期得不到响应，则会抛出时间超出异常

　

- 进程繁忙：

这个的意思和前边的差不多，都是指service层业务太多，顾不上web层的请求，web层的请求就只能一直在那等着，时间长了也就抛出超时异常了。

服务治理中间件：

原理讲解：看了第一种webservice的方法之后，我们采用了第二种方法，即dubbo这种中间件的方式，采用这种方式有什么好处呢？

好处：

　当服务器启动时service会把所有的对象通过dubbo注册给zookeeper，而以后每次需要请求获取对象时，就可以直接从dubbo中异步获取，不需要再去访问service层，这样就解决了服务层网络抖动和服务层进程繁忙的弊端。zeekeeper可以看成是一个数据库，用来存储数据的，具体的原理以后会专门开篇文章描述它。

　这种方式是目前最常用的，起码是我最常用的，顺嘴一提，dubbo是阿里巴巴开发的一款中间件，性能强大，而且这是由中国人自主开发的软件，有木有很自豪。

3.springcloud微服务

微服务架是从SOA架构演变过来，比SOA架构粒度会更加精细，让专业的人去做专业的事情（专注），目的提高效率，每个服务于服务之间互不影响，微服务架构中，每个服务必须独立部署，互不影响，微服务架构更加体现轻巧、轻量级，是适合于互联网公司敏捷开发。

微服务架构特征

微服务架构倡导应用程序设计程多个独立、可配置、可运行和可微服务的子服务。

服务与服务通讯协议采用Http协议，使用restful风格API形式来进行通讯，数据交换格式轻量级json格式通讯，整个传输过程中，采用二进制，所以http协议可以跨语言平台，并且可以和其他不同的语言进行相互的通讯，所以很多开放平台都采用http协议接口。

微服务架构如何拆分

1.微服务把每一个职责单一功能存放在独立的服务中

2.每个服务运行在单独的进程中

3.每个服务有自己独立数据库存储、实际上有自己独立的缓存、数据库、消息队列等资源。

微服务架构与SOA架构区别

1.微服务架构基于 SOA架构 演变过来，继承 SOA架构的优点，在微服务架构中去除 SOA 架构中的 ESB 消息总线，采用 http+json（restful）进行传输。

2.微服务架构比 SOA 架构粒度会更加精细，让专业的人去做专业的事情（专注），目的提高效率，每个服务于服务之间互不影响，微服务架构中，每个服务必须独立部署，微服务架构更加轻巧，轻量级。

3.SOA 架构中可能数据库存储会发生共享，微服务强调独每个服务都是单独数据库，保证每个服务于服务之间互不影响。

4.项目体现特征微服务架构比 SOA 架构更加适合与互联网公司敏捷开发、快速迭代版本，因为粒度非常精细。

为什么选择SpringCloud

因为SpringCloud出现,对微服务技术提供了非常大的帮助，因为SpringCloud 提供了一套完整的微服务解决方案，不像其他框架只是解决了微服务中某个问题。

服务治理: 阿里巴巴开源的Dubbo和当当网在其基础上扩展的Dubbox、Eureka、Apache 的Consul等

分布式配置中心: 百度的disconf、Netfix的Archaius、360的QConf、SpringCloud、携程的阿波罗等。

分布式任务:xxl-job、elastic-job、springcloud的task等。

服务跟踪:京东的hyra、springcloud的sleuth等

SpringCloud简介

SpringCloud是基于SpringBoot基础之上开发的微服务框架，SpringCloud是一套目前非常完整的微服务解决方案框架，其内容包含服务治理、注册中心、配置管理、断路器、智能路由、微代理、控制总线、全局锁、分布式会话等。

SpringCloud包含众多的子项目

SpringCloud config 分布式配置中心

SpringCloud netflix 核心组件

Eureka:服务治理 注册中心

Hystrix:服务保护框架

Ribbon:客户端负载均衡器

Feign：基于ribbon和hystrix的声明式服务调用组件

Zuul: 网关组件,提供智能路由、访问过滤等功能。

###下面我来总结一下分布式框架的优点：

　优点：

1.大幅提高并发访问量(10000+)

2.可以节省成本(因为这种优化仅是从架构方面进行优化，而不需要去配置大量的服务器)

3.实现了服务层与表现层的解耦合

　注：1.其实还有一种方式，即是提升带宽，把带宽搞多一点，但前提是服务器能承受这么大的量。

　2.集群也不是越多越好的，越多的话就会发现，其实并发的提升是有限的。

总结：

说道这里就基本已经讲解了架构的发展历史，当然现在目前还有一种比分布式更火的架构模式，叫做微架构，它是通过服务的原子化拆分，以及微服务的独立打包、部署和升级，可以让小团队的交付周期将缩短，运维成本也将大幅度下降，可以预见，这种架构模式将会越来越受到广大企业的应用与喜爱。

另外，补充一下：

《什么样的项目适合微服务》

其实微服务架构并不是万能的，其实在架构设计中，微服务本身是一件奢侈品。

在复杂度较小的场景中，一体化架构的效率明显更高，当复杂度或者业务量到了一定的程度时，单体应用的生产效率开始极速降低，这时再对他进行微服务化才是合理的，所以，一切脱离实际业务的微服务都是耍流氓。

那么到底什么样的项目适合微服务呢，一般来说，应该满足以下几个条件的一个到两个：

1.产品已经稳定或者已经有明确的产品形态，明确产品的边界，因为微服务扑拓一旦形成，重构的成本超乎想象。

2.公司技术积累较为成熟，有微服务项目经验，开发较为便捷，开发者有足够的控制部署方法，并且高度自动化。

3.业务并发较大，并且集中在一个或者少量几个业务场景下，使用微服务可有效节省资源。

当满足以上条件一个时，其实就可以上微服务了，同时如果是准备技术积累的一些公司，建议逐步试点，然后以点破面，逐步在团队中推行微服务架构。

CDSY,CDSY.XYZ