网站建设 之 分布式微服务

相对于制作，其实更多的是学习。

一个中间路径，算一个应用

一个应用在一个服务器上，多个应用在一个服务器上

一个应用在多个服务器上(集群)，多个应用在多个服务器上(分布式)，这个就涉及到了请求调度的问题，一个请求到底会被哪台服务器处理呢？这用到了反向代理。

所谓微服务，就是将一个应用继续拆分，例如把用户登录，仓库管理，销售管理都拆分出来，分别放到不同的服务器上，或者说不同的容器中，或者说就是单纯的解耦合，这样当流量大时是不是就可以拆分服务器了，易扩展，那么通信就会成为大问题，高并发就会在内部出现。处理这样的问题 就有一套框架存在了，也就是目前流行的 dubbo+zookeeper+acitvemq。

要分布式，这个没得说哈，实际上谁部署到谁那里还是一个文件指定的，备份自然也是自己设计的，备份方式自然也是自己设计的。

要容错性，你只能说交叉存储，一个数据库没办法放到两个地方的硬盘的啊，通信累死。

实际上，分为调用其他微服务的微服务，不调用其他微服务的微服务

被别的微服务调用的微服务，禁止被接口调用，想要被接口调用，再拆分出一个来，这样这个微服务就明显化了，这个微服务崩了怎么办？服务器宕机了，对吧，这个只能重点部署多台，对吧。

不被别的微服务调用的微服务，一般这种微服务直接输入输出接口和获取其他微服务，这个是最末节，最方便被单独化。

涉及状态涉及到数据一致性问题，原则是将整个业务分成两部分, 无状态的服务和有状态的存储。

分布式引来了一系列的问题。

微服务的设计要点

• 服务的拆分和粒度
  服务通用的拆分原则是按业务线的垂直拆分和功能上的水平划分. 至于服务拆分到的粒度则是仁者见仁智者见智, 粒度粗细取决的方面有很多,如业务团队、部署运维、访问流量及硬件资源的限制等.
• 服务接口去状态化
  根据cap理论, 只要涉及状态涉及到数据一致性问题, 在分布式环境下保证一致性就要以牺牲可用性为前提.因此状态是影响服务水平扩展的根本原因, 一个无状态的服务理论上可以随意的迁移和扩展. 然而应用的状态是不可避免的,比如用户订单、登录状态等等.
  我们的原则是将整个业务分成两部分, 无状态的服务和有状态的存储. 服务接口作为计算单元处理用户的请求,根据用户的访问量按需水平扩展,而状态部分则交给专门的数据存储集群来处理,如Redis,数据库等. 内存中不应该保存状态信息.
• 重试及幂等性
  分布式的复杂性在于引入了网络的复杂性, 网络操作存在未知情况. 比如系统之间相互调用时网络超时、丢包、网络分区等等，导致未成功处理或者处理成功未成功接收到响应等情况. 此时常用的手段是重试机制. 重试要求操作具有幂等性.
• 数据库扩展及分布式事务
  数据库是常用保存状态的地方,也是最容易出现瓶颈的地方. 根据cap理论, 传统数据库由于数据库一致性要求很难进行水平扩展. 然而有了分布式数据库可以使数据库的性能可以随着节点增加线性地增加。
  在微服务领域分布式事务是一个绕不开的话题, 在单体架构时期, 数据库本地事务保证了数据的一致性. 在微服务架构中, 由于服务功能的拆分,原本的事务操作可能要跨多个服务, 此时为了保证数据的一致性引入了分布式事务.
  分布式事务的处理方式分两种:强一致性和最终一致性(BASE).
• 数据缓存
  在高并发场景下缓存是非常重要的。有层次的使用缓存能有效减轻系统的压力. 要有层次的使用多级缓存, 缓存数据尽量靠近用户. 比如在web端有一层静态数据缓存、通过cdn，将静态数据放到距离客户较近的地方下载，数据库之上增加redis缓存,动态数据的静态化等等.
• 服务注册发现
  微服务架构服务之间有较强的依赖, 服务之间相互调用必须是动态灵活的. 当服务前移或增加实例时系统能够动态发现.
  常用的发现机制有: 基于注册中心的注册发现机制和基于dns的动态解析机制.
• 统一配置中心
  一类是几乎不变的配置，这种配置可以直接打在容器镜像里面
  第二类是启动时就会确定的配置，这种配置往往通过环境变量，在容器启动的时候传进去
  第三类就是统一的配置，需要通过配置中心进行下发
• 熔断，限流，降级
  服务要有熔断，限流，降级的能力，当一个服务调用另一个服务，出现超时的时候，应及时返回，而非阻塞在那个地方，从而影响其他用户的交易，可以返回默认的托底数据。
• 全方位的监控
  当系统非常复杂的时候，要有统一的监控，主要有两个方面，一个是是否健康，一个是性能瓶颈在哪里。

拆分的方式一般有水平拆分以及垂直拆分。垂直拆分把一个应用拆成松耦合的多个独立的应用，让应用可以独立部署，有独立的团队进行维护。水平拆分把一些通用的，会被很多上层服务调用的模块独立拆分出去，形成一个共享的基础服务，这样拆分可以对一些性能瓶颈的应用进行单独的优化和运维管理，也一定程度防止了垂直拆分的重复造轮子。对于性能优化，必须水平拆分了。

SOA也叫面向服务的架构，从单体服务到SOA的演进，需要结合水平拆分以及垂直拆分。SOA强调用统一的协议进行服务间的通信，服务间运行在彼此独立的硬件平台但是需通过统一的协议接口相互协作，也即将应用系统服务化。举个易懂的例子，单体服务如果相当于一个快餐店，所有的服务员都是一样的，又要负责收银结算，又要负责做汉堡，又要负责端盘子，又要负责打扫，服务员之间不需要有交流，一个用户来了一个服务员从前到后负责到底。SOA相当于让服务员有职责分工，收银员负责收银，厨师负责做汉堡，保洁阿姨负责打扫等等。所有服务员需要同一种语言交流，方便工作协调。

让一个超大的服务逻辑，解耦合为一个个小服务，均匀的分布在各自的服务器中。微服务就微在这。每个教研组就是一个微服务集群。他们提供同样的服务，而注册中心Eureka就是这个存放这个教研组老师名单的地方，学生们想先访问这个注册中心获取教师名单，然后根据相应的负载方法去访问各自老师。不至于让集群中某一老师累死也不至于让某一老师闲死。注意集群里都是相同的服务，集群解决的是一个服务，多服务器的问题

多微服务，多服务器问题可转化为单微服务，多服务器，进而转化为单微服务，单服务器。

Zuul网关，网关可以理解为权限路由。

Hystrix熔断器相当于一个教研组的老师死绝了之后自动激活的智能机器人，但它只能处理一些简单的工作，例如报警。对外来学生说老