本文共 3145 字，大约阅读时间需要 10 分钟。

一、单体与集群

1.1 问题

维护不方便，资源占用高，但是调用方便，可以直接获取对象调用数据共享，比如session，并发低，容易崩溃

1.2 解决单点问题

集群，集群并不能解决资源占用高的问题，但是提高了可用性和并发量，但是带来了问题：

（1）如何分发请求（负载均衡） （2）状态共享（session共享）

1.2.1 负载均衡

负载均衡就是从一堆一样的东西里挑一个

• 随机挑选
• 轮询
• 能者多劳（权重）
• 哈希（让一个主机一直处理）
• 最少活跃数（空闲主机处理）

1.2.2 session共享（状态共享）

• 保存到redis
• 同步到其他服务器（不可选，因为需要占用其他服务器大量资源来同步数据）
• 如果使用功能hash模式的话，没有共享问题，但是注意可能会产生故障问题，hash所指向的服务器会出现问题，所以我们使用一些特定算法来对状态数据进行操作，比如jwt

二、拆分与合并

2.1 准则

按照项目具体清空进行拆分

2.1.2 拆分类型

（1）按照模块拆分

登录、注册和商品拆分出来

（2）按照访问量拆分

商品的查询拆分出来

订单的查询拆分出来

优惠券拆分为发券和用券系统

（3）按照查询

查询、修改

2.2 合并

我们把代码拆分，但是最终还要互相调用。

分布式，节点多，机器多，每个功能对应的机器到底是哪个我们不知道，而且这些机器会随着访问量进行增删

2.2.1 注册中心

我们不能主动找到服务器在哪，但是服务器可以主动告诉我们它在哪。

注册中心地址是确定的，然后所有的服务器去注册中心进行注册，注册其实就是把自己的信息通过注册中心提供的接口写进去，注册中心会保存。

• zookeeper 保存的是接口的名字， /dubbo/接口名/providers(consumers,routers路由网关负载均衡) 在dubbo下有很多的接口，都是保存的服务，按照规则，我们可以放入，也可以获取调用服务。一致性。
  一堆的api，主要是和dubbo的整合，但是dubbo帮我们做了很多事情
• eureka 内存里面，保存到容器，比如map容器、list容器等等。可用性。

server整合：导入server依赖包，写个配置文件来配置地址、帐号和密码，添加一个enableEurekaServer

client整合：导入client依赖包，配置server的地址密码等信息，添加注解enableEurekaClient,enableDiscover

cap理论：一致性，可用性，分区容错性，一致和可用是有冲突的，需要权衡。

微服务属于分布式，提供分布式方案的有：

springCloud，采用http调用 dubbo+zookeeper，采用RPC调用，依赖java对象，比较局限

2.2.2 负载均衡 ribbon

导入依赖包，在resttemplate上面加注解loadblanced，然后我们调用服务的时候主机

这是一个客户端侧的负载均衡

客户端负载均衡：ribbon先从eureka上面获取到所有服务器，然后从中间选择一个，这就是客户端负载均衡。

服务端负载均衡：客户端连接一个负载均衡服务器ribbon，告诉它我要一个服务，然后服务器在里面会找到所有服务列表，挑选一个返回。

2.2.3 feign

整合ribbon的

也是一个规则，地址路径的拼接方式规则，通过类注解参数来声明访问什么服务，通过方法参数来传递请求参数

2.2.4 hystrix

可能出现的问题：

• 流量或者并发太高，需要限制一部分请求，那么被限制的就会出现问题。
• 超时，hystrix的超时机制是可以指定超时时间，信号量只能被动等待下游服务超时
• 熔断，多次请求下游服务一直失败，当再次请求的时候就不去了直接认为失败，10秒20次，或者
• 隔离机制，独立线程池和信号量，将服务隔开，互不影响
• 为了避免出现问题，我们提前做了降级，比如在高并发时间段，不允许用户进行操作

降级机制：当我们的请求出现问题的时候，为了防止出现更多的级联故障（A>B>C>D>E，如果E抛出异常，或者E阻塞，则其他服务都会异常或者阻塞，阻塞会导致前面的机器可能线程池被消耗完毕，正常请求也拿不到线程资源，全部卡死）或者用户体验不好（出现系统错误页面），即出现问题，不能将正常数据返回给调用者，我们需要找替代方式进行处理。

2.2.5 网关

程序的统一入口，可以做我们想做的事情，比如为了解决功能太多，需要的服务器太多导致域名太多，产生的跨域问题以及代码编写的复杂度问题，可以将所有的服务器统一交给网关管理，即只需要和网关通信。

网关可以进行统一的一些数据校验，判断，规则审查，动态路由等等。

参数的判断、校验、签名、token、动态路由、发送日志等等。

动态路由

http://网关的端口/服务的名字/地址/参数

http://网关的端口/服务的别名/地址/参数 别名需要在配置文件中配置，也就是说每增删服务，必须要修改一次配置文件，是不合理的，违背开闭原则。

我们配置的服务实际上是通过requestcontest中put的两个参数，即receiveID和receiveURL来进行的映射。

因为服务调用是客户端或者是用户执行的，所以我们要想办法通过用户传递来的参数来找到服务的id和url即可

这是典型的key-value，我们可以在redis中将这些关系放好，根据用户传递来的参数随时获取即可，就能随时更新，所以我们只要定义一个规则，即参数和服务之间的映射规则。

三、MQ

消息队列，应用之间通信，即服务器和服务器之间的通信，主要是来取代同步操作，很多操作都是异步的

ES

存储的服务器，模糊查询性能很高

分词器，一段内容如何拆分 倒排索引，根据内容找索引，然后根据索引找内容 库和表都可以动态创建

四、微信公众号

在微信公众号中查询日志数据

微信公众号 ---> 区分文本消息 ---> 规则 ---> 要求用户先输入xxx，然后输入的内容就是查询条件 ---> restTemplate(java中发请求的类) ---> 日志数据 ---> ES ---> 接口（网关对应接口，都是各个模块服务）

微信公众号开发的BUG

在使用微信公众号进行开发的时候，要注意，有一个bug，就是当点击使用【click】关键字开头的时候，会不断报错，说是编码问题，但其实不是编码问题，而是腾讯公司本身的问题，我们不能使用【click】关键字

click1.setType("click");

海尔的ERP系统

需要统计在我们的平台的销售记录，怎么统计？

只要发起请求的就是客户端 | ERP发起请求—>网关—>对应的接口参数—>appkey—>数据整合 给用户返回的数据需要经过10个服务获取得到

五、分布式

jwt身份认证组件，和shiro很类似，一般用于注册和登录，保证一处登录后，使用其他相关的服务的时候不需要再登录，但是需要用过滤器进行认证。

网关主要作用是过滤、认证、监控等等，通过网关，才能访问注册中心获取服务，这中间需要redis缓存。

注册中心有Eureka和zookeeper，主要作用是将服务注册进去，然后提供路径或者接口，供用户调用。

MQ和ElasticSearch可以配合使用，一般网关调取服务，执行服务，给用户反馈结果等主线操作不变，在其中会拉去副线，给MQ，进行日志处理，然后给到ElasticSearch，ElasticSearch可以存储日志信息，并会从数据库获取相关的数据进行备份存储，向外提供的是查找功能。

当数据库数据发生更新的时候，会通知给MQ，然后MQ也会传递给ElasticSearch，实现更新。

六、加餐

转载地址：http://vvgzi.baihongyu.com/