一文看懂Java微服务架构，WEB2.0，垂直架构，分布式架构，微服务架构

Java微服务架构

目录：

1. 了解开发环境&生成环境
2. WEB1.0 & WEB2.0
3. 垂直架构
4. 分布式架构
5. 微服务架构

1.了解开发环境&生产环境

1.1 开发环境

平时在写代码的时候，大多都在WIN10/WIN7/Mac.

这些系统都可以称为开发环境。咱们为了更高效的开发应用程序，安装很多的软件，会

导致操作系统不安全，稳定性降低。

2.1. 生产环境（学会如何操作，Linux操作系统）

在生产环境中，操作不会采用Win10/Mac。这种操作系统相对不安全，生产环境是要面向全体用户的，一般会采用专业的操作系统。

大多数市面上使用的都是基于Linux的操作系统，还有Windows版本的服务器操作系统

Windows 2003 service

2. WEB1.0 & WEB2.0

2.1. WEB1.0时期

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

单体架构就足以应对

2.2. WEB2.0时期

随之到来的WEB2.0 实现了ADSL拨号上网，宽带提速，最高可以达到8M 用户量也就不断增加，一些门户网站也开始活跃，项目就需要考虑安全性，和稳定性。

在基于单体架构的设计中，无法满足WEB2.0对项目的需求，需要在单体架构上搭建集群（多个服务器），

在搭建集群之后，可以提升项目的稳定性，并且并发量增加，也可以承受住

2.3. 搭建集群后出现的问题

1. 用户的请求到底要发送到那台服务器上，如何才能保证请求平均的分发给不同的服务器，从而缓解用户量增加的压力
2. 编写项目时，如果用户登录成功，将用户的标识存放到的Session中，在搭建集群之后，数据共享问题
3. 当数据量特别庞大时，如果还直接去数据库查询，速度很慢，如何提升查询效率
4. 针对大家在搜索一些数据时，where content like '%#{xxx}% ’

2.4. 针对上述问题，如何解决（中间件）

1.Nginx，用来解决用户请求平均分发 2.Redis， 用来解决数据共享并实现缓存功能 3.ElacticSearch，用来解决搜索数据的功能

3. 垂直架构

比如项目包含了三个模块，用户模块，商品模块，订单模块，商品模块。

一般商品浏览的商品模块流量最大，为了防止商品模块压力过大，一般直接有效的方法就是搭建集群。

在单体架构的集群上去搭建，效果相对比较差。随着项目的不断更新，项目中的功能月越来越多，最严重的可能会导致项目无法启动

关于单体架构中，完美的体验了低内聚，高耦合。（开发的要求是高内聚，低耦合）

为了解决上述的各种问题，更新了垂直架构

4. 分布式架构

4.1 项目迭代

随着项目的不断迭代，新老功能之间需要相互交互，服务器与服务器之间需要通信的。

项目一般分为三层的 Controller Service Dao。导致程序变慢的重灾区，一般是Service和Dao，在搭建集群时，确实针对三层都搭建集群，效果不是很好。

架构从垂直架构，演变到了分布式架构

分布式架构落地的技术：

为了解决各个服务之间的通信，国内通讯的方式有两种： 1.Dubbo 采用的RPC方式 2.SpringCloud 采用的HHTP方式

5. 分布式架构常见问题

5.1服务之间的异步通讯 在使用分布式架构之后，服务之间的通信都是同步的。 在一些不是核心业务的功能上，咱们希望实现异步通讯。 为了实现服务之间的异步通讯，需要学习MQ. MQ-RabbitMQ（消息队列）

5.2 服务之间通信地址的维护 由于服务越来越多，每个服务的访问地址都是不一样的。协议：//地址：端口号

由于我们的模块繁多，并且模块搭建的集群数量增加，会导致其他模块需要维护各种ip地址等信息，导致项目的维护性极低，耦合性变高，并且也无法实现负载均衡的功能

需要使用一个技术来解决当前问题： Eureka注册中心帮助我们管理服务信息 ：实现通讯地址维护 Robbin可以帮助我们实现服务之间的负载均衡 ：实现服务之间的负载均衡

5.3 服务降级

在上述的架构中，如果说订单模块出现了问题。

只要是涉及到订单模块的功能，全部都无法使用。

可能会导致服务器提供的线程池耗尽，给用户友好的提示都是无法做到的

为了解决上述的问题，使用Hystrix处理，

Hystrix提供了线程池隔离的方式，避免服务器线程池耗尽，在一个服务无法使用时，可以提供断路器的方式解决

使用Hystrix 帮我们实现断路器和隔离，并最终服务降级

Eureka,Robbin,Hystrix 都是SpringClod中的组件

5.4 海量数据 海量数据最终会导致数据库无法存储全部的内容。即便数据库可以存储海量的数据，在查询数据时，数据库的响应是极其缓慢的

在用户高并发的情况下，数据库也是无法承受住的 为了解决上述的问题，可以基于MyCat实现数据库的分库分表。

6. 微服务架构

虽然已经将每个模块独立的做开发，比如商品模块，压力最大的是商品的查询。

在单独模块中再次拆分项目的方式就可以称为微服务架构。微服务架构其实属于分布式架构的

6.2 容器化技术

为了解决模块过多，运维成本增加的问题。采用Docker容器化技术来帮助我们管理

后期在学习的时候，也需要大量的软件，可以使用Docker来帮助我们按照软件。

6.3 分布式架构下的其他问题

分布式架构帮助我们解决了很多问题，但是随之也带来了跟多问题：

1. 分布式事务：

最传统的操作事务的方式，是通过Connection连接对象的方式操作，

Spring也提供了声明式事务的操作，为了解决事务的问题，后续会使用到RabbitMQ 或者使用到 LCN 方式解决

2.分布式锁：

传统的锁方式，一种是synchronize 或者 Lock锁，在分布式环境下，传统的锁是没有效果的。为了解决锁的问题，后续会使用Redis 或者 Zookeeper来解决

3.分布式任务：

在传统的定时任务下，由于分布式环境的问题，可能会造成任务重复执行，一个比较大的任务希望可以拆分。为了解决这个问题，后续会使用Redis + Quartz 或者 Elastic-Job。