微服务

互联网架构演进之路
单体架构
垂直架构（模块化的开发MVC）
创业初期讲究快速迭代，架构的选型只有合适不合适

• 小：每个服务专注于一个功能（细粒度）
• 独：单个微服务都是独立的进程（独立部署）
• 轻： 轻量级通信
• 松：松耦合，解耦，快速迭代
  微服务架构技术选型：
  java系：spring cloud和阿里开源的Dubbo
  Go系：Go Micro，kit,kite
  微服务注册：
  微服务的存活状态（心跳维持）
  微服务之间的关系

集群与分布式

• 集群是个物理形态，分布式是个工作方式
• 分布式：一个业务拆分成多个子业务，部署在不同的服务器上
• 集群：同一个业务部署在多个服务器上
  分布式的每一个节点都可以做成一个集群，而集群并不一定是分布式的
  举例：就比如新浪网，访问的人多了，他可以做一个群集，前面放一个响应服务器，后面几台服务器完成同一业务，如果有业务访问的时候，响应服务器看哪台服务器的负载不是很重，就将给哪一台去完成。
• 集群有一个组织性，一台服务器垮了，其它的服务器可以顶上来。
  分布式的每一个节点，都完成不同的业务，一个节点垮了，那这个业务就不可访问了。
  好的设计应该是分布式和集群的结合，先分布式再集群，具体实现就是业务拆分成很多子业务，然后针对每个子业务进行集群部署，这样每个子业务如果出了问题，整个系统完全不会受影响。
  3分钟读懂何为分布式、微服务和集群！

微服务

• 微服务原理图
  

  组织必须要意识到往微服务的迁移就意味着往分布式系统进行迁移，在得到它所有收益的同时，也伴随着分布式系统的所有缺点，包括必须要处理延迟、认证与授权、无法抵达的消息。

微服务的优点

微服务优点

什么时候进行服务化

image.png

服务化拆分的两种姿势

image.png

服务化架构面临的问题

• 服务如何定义。 对于普通单体应用而言，不同模块之间进行交互时，通常是以类库的方式提供各个模块的功能。对于微服务来说，每个服务都运行在各自的进程之中，应该是以何种形式传达自己的信息呢？答案是接口，无论采取哪种通信协议，是HTTP还是RPC，服务之间的调用都通过接口描述来约定，约定内容包括接口名、接口参数和返回值。
• 服务如何发布与订阅。 单体应用部署在war包里，接口之间的调用属于进程内的调用。而拆分微服务独立部署后，服务提供者该如何对外暴露地址，服务调用者该如何查询所需要调用的服务的地址呢？这个时候就需要类似登记的地方，能够记录每个服务提供者的地址以供服务调用者查询，在微服务架构中，这个地方就是注册中心。
• 服务如何监控。
  服务如何监控
• 服务如何治理。 拆分为微服务架构后，服务的数量变多了，依赖关系也变复杂了。如果一个服务的性能出现问题，依赖的服务势必会受到影响。可以设定一个调用性能阈值，如果一段时间内一直超过这个值，那么依赖的服务调用可以直接返回，这就是熔断，也是服务治理的最常用手段。
• 故障如何定位。 一次用户调用可能依赖多个服务，每个服务又部署在多个节点上。如果用户调用出现问题，你需要一种解决方案能够将一次用户请求进行标记，并在多个依赖的服务系统中依次传递，以便串联所有路径，从而进行故障定位。

微服务调用流程

微服务调用流程

• 提供服务的一方向注册中心注册服务，声明自己能够提供哪些服务以及服务地址，完成服务发布。
• 消费者请求注册中心，查询所需要的服务地址，然后以约定的通信协议向服务提供者发起请求，得到请求结果后再按照约定协议解析结果。
• 在服务的调用过程中，服务的请求耗时、调用量以及成功率都会被记录下来用作监控，调用经过的链路信息也会被记录下来，用于故障定位和问题跟踪。在这期间，如果调用失败，可以通过重试等服务治理手段来保证成功率。

微服务架构下，服务依赖的组件

• 服务描述
• 注册中心
• 服务框架
• 服务监控
• 服务追踪
• 服务治理
  熔断

服务发布与引用

image.png
image.png
image.png
image.png
image.png
image.png
image.png

RPC和MQ对比及其适用/不适用场合

https://blog.csdn.net/glory1234work2115/article/details/51728172

如何注册和发现服务

服务发布和引用常用的三种方式：RESTful API、XML配置和IDL文件
注册中心的原理和实现方式

• 在微服务架构下，主要有三种角色：服务提供者、服务消费者和服务注册中心
  首先，rpc server会根据服务发布文件sever.xml中的配置信息，向注册中心注册自己的服务，并向注册中心定期发送心跳汇报存活状态。
• 服务消费者会根据服务引用文件client.xml中的配置信息，向注册中心订阅服务，把注册中心返回的服务节点列表缓存在本地内存中，并与rpc server建立连接。
• 当rpc server发生变更时，注册中心会同步变更，rpc client端会感知到注册中心的变化刷新本地缓存节点列表

• rpc client从本地缓存的服务节点列表中，基于负载均衡原理选择一台rpc server进行调用。

  
  image.png

ZooKeeper

分布式的优缺点

什么是Apache zookeeper？

• apache zookeeper本身是集群（节点组）使用的一种服务，用于自身协调，并通过稳健的同步技术维护共享数据。
• zookeeper本身就是一种分布式应用程序，为写入分布式应用程序提供服务。
  分布式应用程序提供了很多好处，但它们也抛出了一些复杂和难以解决的挑战。ZooKeeper框架提供了一个完整的机制来克服所有的挑战。竞争条件和死锁使用故障安全同步方法进行处理。另一个主要缺点是数据的不一致性，ZooKeeper使用原子性解析。
• ZooKeeper集合在实际生产环境中必须至少有三个节点(半数以上可靠原则)

zookeeper架构

image.png
zookeeper组件

写入：写入过程由leader处理。leader将写入请求转发到所有的znode，并等待znode的回复，如果有一般的znode回复，则写入完成。

集群部署

注册中心作为服务提供者和服务消费者沟通的重要桥梁，其重要性不言而喻，所以注册中心一般采用集群部署来保证高可用，并通过分布式一致性协议来保证集群中不同节点间的数据保持一致。

zookeeper实现分布式锁的原理

• 每个客户端对某个功能加锁时，在zookeeper上的与功能对应的指定节点的目录下，生成一个唯一的临时顺序节点。
• 所有临时顺序节点中序号最小的，就是当前持有锁的节点
• 释放锁时将这个临时顺序节点删除即可
  https://blog.csdn.net/scandly_java/article/details/51331963

socket通信

image.png
image.png

用户如何追踪微服务

image.png

分布式系统的重要理论CAP

• 分区容错性Partition tolerance
  分布式系统中包含多个节点，节点之间通过网络互连，正常情况下通过通过网络从一个节点可以正常访问到任何其他节点的数据。但是网络故障的情况下，导致整个网络被分成互不连通的区域，这叫做分区。一旦出现分区，一个节点就无法访问其他节点上的数据了，最好的办法是把节点上的数据复制到其他节点上，这样即使出现了分区，也能访问其他节点数据，这叫做分区容错性。
• 数据一致性Consistency
  把数据复制到不同节点可能出现数据不一致的情况，一般保证数据最终一致性。
• 可用性Availability
  分布式三个指标
  http://www.ruanyifeng.com/blog/2018/07/cap.html
• 什么场合，可用性高于一致性？
  举例来说，发布一张网页到 CDN，多个服务器有这张网页的副本。后来发现一个错误，需要更新网页，这时只能每个服务器都更新一遍。
  一般来说，网页的更新不是特别强调一致性。短时期内，一些用户拿到老版本，另一些用户拿到新版本，问题不会特别大。当然，所有人最终都会看到新版本。所以，这个场合就是可用性高于一致性。
• 什么场合，一致性高于可用性？
  牺牲可用性来保证一致性，最典型的例子就是ZooKeeper。ZooKeeper集群里只有一个leader，而且leader在不可用的时候，会通过paxos算法重新选举新的leader，这个leader的作用是保证在写信息的时候指向leader写入，leader会同步信息到followers，这个过程就可以保证数据一致性。但如果多个zookeeper之间网络出现了问题，造成出现多个leader，发生脑裂的话，注册中心就不可用了。

负载均衡的算法

• 随机算法
• 轮询算法
  按照固定的顺序，把可用的服务节点，挨个访问一次。
  在实现时，把所有可用节点放到一个数组里，按照顺序访问
• 加权轮询算法
  给每个节点赋予权重
• 最少活跃连接算法
  在挑选节点时，选择最少连接数的节点访问
• 一致性hash算法
  通过某个hash函数，把同一来源的请求都映射到同一个节点上，具有记忆功能，只有该节点不可访问时，请求才会分配到其他相邻节点上。

总结

• 当你的团队准备对业务进行微服务架构改造时，要避免一上来就将整个业务进行服务化拆分、追求完美。这是很危险的，一切的业务改造都应当以给业务创造价值为宗旨，所以业务的稳定性放在第一位，切记好高骛远！
  正确的方法是应该从众多业务中找到一个小的业务进行试点。前期的技术方案以满足这个小业务的需求为准，力求把这个小业务的微服务架构落地实施，从中发现问题并给以解决，然后才可以考虑更大规模的推广。这样的话技术微服务架构的改造因为技术方案不成熟对业务造成了影响，也只是局限在一个小的业务范围内，不会对整体业务造成大的影响。