架构演进

一、开发环境&生产环境

1. 开发环境

平时在写代码时大多都在是 Win10/Win7/Mac这些系统都可以称呼为开发环境，咱们会为了更高效的开发应用程序安装很多很多的软件会导致操作系统不安全稳定性降低。

2. 生产环境

在生产环境中操作系统不会采用win10/Mac这种操作系统相对不安全，生产环境是要面向全体用户的一般会采用专业的操作系统，大多市面上使用的都是基于linux的操作系统还有 Windows版本的服务器操作系统 Windows2003 service。

二、WEB1.0 & WEB2.0阶段

1. WEB1.0时期

在MEB1.0时期，由于带宽不足这时的项目大多是内容少，用户量也不多甚至有一些项目不需要对外开放,对安全性和稳定性的要求是不高的。
单体架构就足以应对。

2. WEB2.0时期

随之到来的MEB2.0实现了ADSL拨号上网带提速，最高可以达到8M用户量也就不断增加一些门户网站也开始活跃，项目就需要考虑安全性和稳定性，在基于上面的单体架构图中无法满足WEB2.0对项目的需求。
在单体架构的基础上去搭建集群。
在搭建集群之后，可以提升项目的稳定性，并且并发量增加，也可以承受住。

3.0 搭建集群出现的问题

1.用户的请求到底要发送到哪台服务器上如何保证请求平均的分发给不同的服务器，从而缓解用户量增加的压力。
2.编写项目时如果用户登录成功了将用户的标识放到 Session域中在搭建集群之后，数据共享问题。
3.当数据量特別庞大时如果还直接去数据库查询速度很慢，如何提升查询效率。
4.针对大家在搜索一些数据时， where content like “％#{xxx}%”。
为了解决上述的问题需要使用到三门技术：
Nginx-解决用户请求平均分发。
Redis-解决数据共享并实现缓存功能。
Elasticsearch-解决搜索数据的功能。

三、垂直架构

比如项目包含了三个模块，用户模块，商品模块订单模块。
商品模块压过大，一般最直接有效的方式就是搭建集群在单体架构的集群上去搭建，效果相对比较差。
随着项目的不断更新项目中的功能越来越多，最严重可能会导致项目无法启动。
关于单体架构中，完美的体现了低内聚高耦合。
为了解决上述的各种问题，演进出了垂直架构。

四、分布式架构

1. 项目迭代

随着项目的不断迭代，新老功能之间需要相互交互，服务器和服务器之间是需要通讯的。
项目一般是分为三层的， Controller， Service，Dao。导致程序变慢的重灾区，一般是 Service和Dao，在搭建集群时确实针对三层都搭建集群，效果不是很好。
架构从垂直架构演变到了分布式架构。
分布式架构落地的技术：国内通讯的方式有两种
Dubbo RPC
Springcloud HTTE

五、分布式架构常见问题

1. 微服务之间的异步通讯

使用分布式架构之后，服务之间的通讯都是同步的。
在一些不是核心业务的功能上咱们希望可以实现异步通讯。
为了实现服务之间的异步通讯需要学些 MQ-RabbitMQ。
分布式实现异步通讯。

2. 服务之间通讯地址的维护

由于服务越来越多每个服务的访问地址都是一样的。
协议://地址:端口号
由于模块繁多，并且模块搭建的集群数量増加会导致其他模块需要维护各种i地址等信息，导致项囯的维护性极低耦合性变高，并且也无法实现负载均衡的功能。
需要使用一个技术来解决当前问题:
Eureka注册中心帮助我们管理服务信息。
Robbin可以帮我们实现服务之间的负载均衡。

3. 服务降级

在上述的架构中如果说订单模块出现了问题。
只要是涉及到订单模块的功能，全部都无法使用。
可能会导致服务器提供的线程池耗尽给用户友好的提示都是无法做到的。
为了解决上述的问题使用Hystrix处理。
Hystrix提供了线程池隔离的方式避免服务器线程池耗尽，在一个服务无法使用时，可以提供断路器的方式来解决。
使用 Hystrix帮我们实现断路器和隔壁，并最终服务降级。

4. 海量数据

海量数据会导致数据库无法存储全部的内容。
即便数据库可以存储海量的数据，在査询数据时，数据库的响应时及其缓慢的。
在用户高并发的情况下，数据库也是无法承受住的。
为了解决上述的问题，可以基于Mycat实现数据库的分库分表。

六、微服务架构

1. 微服务架构

虽然已经将每个模块独立的做开发，比如商品模块，压力最大的时商品的查询。
在单独模块中再次拆分项目的方式就可以称之为微服务架构。
微服务架构，在分布式架构的基础上再次拆分。

2. 模块过多，运维成本增加

为了解决模块过多，运维成本增加的问题。
采用 Docker容器化技术来帮助我们管理。
后期在学习的时候，也需要大量的软件，可以使用 Docker来帮助我们安装软件。

3. 分布式架构下的其他问题

分布式架构帮助我们解决了很多的问题，但是随之也带来了很多问题:
1.分布式事务
最传统的操作事务的方式，是通过 Connection链接对象的方式操作， Spring也提供了声明式事务的操
作。为了解决事务的问题，后续会使用到 RabbitMQ|LCN方式来解决。
2.分布式锁
传统的锁方式， synchronized, Lock锁，在分布式环境下，传统的锁是没有效果的。为了解决锁的问题
后续会使用到 Redis, Zookeeper来解决。
3.分布式任务
在传统的定时任务下，由于分布式环境的问题，可能会造成任务重复执行，一个比较大的任务，需要可以拆分。
为了解决这个问题，后续会使用到 Redis+ Quartz| Elastic-Job。