14、服务化：微服务架构，究竟解决什么问题？

• no14：在服务化前后的互联网的常见架构示意图
  • 服务化前
  • 
  • 服务化后
  • 
• no14：没有服务化前的痛点
  • 1.代码到处拷贝
    • 
  • 2.底层复杂性扩散
    • 
  • 3.公共库耦合
  • 4.SQL 质量无法保障
    • 
  • 5.不易扩展，数据库耦合
    • 
• no14：服务化的好处
  • 1.复用性，消除代码拷贝
    • 
  • 2.专注性，防止复杂性扩散
    • 
  • 3.解耦合，消除公共库耦合
  • 4.高质量，SQL 稳定性有保障
    • 
  • 5.易扩展，消除数据库解耦合
  • 6.(最重要)高效，对业务调用方的研发效率提升了
• no14：服务化后的潜在问题有哪些？
  • 1.系统复杂性上升
  • 2.层次间依赖关系变得复杂
  • 3.运维，部署更麻烦
  • 4.监控变得更复杂
  • 5.定位问题更麻烦

15、服务化：微服务架构，粒度多少合适？

• no15：微服务化架构粒度拆分实践一：统一服务层
  • 
  • 业务不是特别复杂的时候，统一整个服务层，所有数据都通过一个统一的服务层来进行访问
  • 缺点：一旦代码出故障，就将影响整个服务
• no15：微服务化架构粒度拆分实践二：一个子业务一个服务(最佳实践)
  • 
  • 在服务层进行垂直拆分，一个子业务抽象出一个服务，数据层也按照子业务垂直拆分
  • 当业务连接关系变得复杂时，加入网关分发层来消除这个网状关系，并在协议设计的时候加入一个协议号服务号，分发层通过协议号服务号将请求路由到相关的子业务服务
  • 
• no15：微服务化架构粒度拆分实践三：一个数据库一个服务
  • 
• no15：微服务化架构粒度拆分实践四：一个接口一个服务
  • 
  • 需要语言特性的支持，如 go 可以这么使用
• no15：微服务化架构拆成细粒度优缺点
  • 优点
    • 服务能够独立部署，扩容缩容相对方便
    • 能更有效地提高资源利用率
    • 耦合度相对减小
    • 容错性相对更好
    • 扩展性也会更好
  • 缺点
    • 服务数量变多
    • 系统复杂性增加
    • 依赖关系复杂性增加
    • 运维复杂性增加
    • 监控更复杂
    • 定位问题更复杂

16、服务化：微服务架构，必须搞定高可用！

• no16：高可用是什么？
  • 减少系统不能提供服务的时间
• no16：如何判断是否高可用？
  • 随机关停一台线上服务器，如果对用户的服务不受影响，那么系统就是高可用的
• no16：如何保障系统的高可用
  • 1.集群化(冗余)
  • 2.故障自动转移
• no16：常见微服务分层架构？
  • 
• no16：微服务分层架构如何保证「端」到「反向代理」的高可用
  • 
  • 通过 keepalived + 虚 IP 来实现
• no16：微服务分层架构如何保证「反向代理」到「站点应用」的高可用
  • 
  • 通过站点层的冗余来实现
• no16：微服务分层架构如何保证「站点应用」到「微服务」的高可用
  • 
  • 通过服务层的冗余来实现，上游有服务连接池
• no16：微服务分层架构如何保证「微服务」到「缓存」的高可用(memcache)
  • 
• no16：微服务分层架构如何保证「微服务」到「缓存」的高可用(redis)
  • 
  • 但很多时候缓存不需要保证高可用，只要不「雪崩」压垮数据库就行
    • 
    • 将缓存进行水平切分，这也是个集群，但只是用来做分片，并不做数据冗余，在上游设置代理，即进行完水平切分的入口
• no16：微服务分层架构如何保证「微服务」到「数据库」的高可用
  • 如果做了读写分离，必须保证
  • 「微服务」到「读库」的高可用
    • 
    • 通过读库的冗余化集群实现的
  • 「微服务」到「写库」的高可用
    • 
    • 通过写库的冗余化集群实现的，如 MySQL 可通过设置双主相互同步

17、服务化：微服务架构，必须搞定高并发！

• no17：什么是高并发？
  • 通过设计方案，保证系统能够同时并行的处理很多用户的很多请求
• no17：高并发相关的常见指标有哪些？
  • 1.响应时间(Response Time)
  • 2.吞吐量(Throughput)
  • 3.每秒查询率 QPS(Query Per Second)
  • 4.并发用户数
• no17：提升系统并发处理能力的方法论？
  • 1.垂直扩展(Scale Up)
    • 1.提升单机硬件性能
    • 2.提升单机架构性能
    • 业务早期建议使用，因为速度最快
  • 2.水平扩展(Scale Out)
• no17：常见微服务分层架构
  • 
  • 要想做到整体的性能无限，就必须做到每一层都能够实现水平扩展性能无限
• no17：常见微服务分层架构的反向代理层的水平扩展
  • 
  • 之前都是通过 lvs 和 f5 的垂直扩展的方式，这都是有性能上限的，反向代理的水平扩展是通过 DNS 轮询实现的，DNS server 对于同一个域名配置不同的 nginx 外网 IP
• no17：常见微服务分层架构的站点应用层的水平扩展
  • 
  • 通过反向代理层实现
• no17：常见微服务分层架构的微服务的水平扩展
  • 
  • 通过服务连接池去实现的，站点层通过 rpc client 调用下层的服务层 rpc server，rpc client 会建立多个服务连接，当服务称为瓶颈的时候，只要增加服务节点的数量，rpc client 会建立新的连接
• no17：常见微服务分层架构的数据层(缓存，数据库)的水平扩展
  • 需求
    • 1.存储容量的扩展，无限容量
    • 2.处理能力的扩展，无限读性能，无限写性能
  • 根据数据的范围水平切分
    • 
    • 优点
      • 规则简单
      • 数据的均衡性比较好
      • 容易扩展
    • 缺点
      • 虽然保证数据层是均衡的，但读写请求不一定是均衡的
  • 按照哈希水平切分
    • 
    • 优点
      • 规则简单
      • 数据均衡性非常好
      • 请求均衡性非常好
    • 缺点
      • 不容易扩展，扩展可能需要进行数据迁移

18、服务化：微服务架构，必须搞定负载均衡！

• no18：什么是负载均衡
  • 将请求或者数据均匀地分摊到多个操作单元上执行
    • 1.同构，重点在于「均匀」
    • 2.异构，重点在于「负载与能力匹配」
• no18：常见微服务分层架构，保证负载均衡的思路
  • 
  • 实现每个上游都实现对下游的均匀访问，即可实现系统整体的均匀分摊
• no18：常见微服务分层架构，反向代理层的负载均衡
  • 
  • DNS 服务器使用 DNS 轮询的方式，即可实现 Nginx 的负载均衡
• no18：常见微服务分层架构，站点应用层的负载均衡
  • 
  • nginx 使用轮询的方式，将请求路由到多个站点应用的后端
• no18：常见微服务分层架构，微服务的负载均衡
  • 
  • 通过连接池实现的，可使用随机或轮询等方式保证多个微服务的下游的请求是均匀的
• no18：常见微服务分层架构，数据层(缓存，数据库)的负载均衡
  • 1.数据，均衡
  • 2.请求，均衡
  • 按照数据范围水平切分
    • 
    • 数据负载是均衡的，水平负载未必均衡，如新用户可能更活跃
  • 哈希水平切分
    • 
    • 数据、请求的负载都比较均衡，同构节点的服务器的均衡比较容易
• no18：常见微服务分层架构，异构服务器负载均衡，方案一：静态权重
  • 
  • 为下游每个微服务节点设置一个静态权重，表示微服务的处理能力，来调配连接池
  • 优点
    • 简单粗暴
  • 缺点
    • 无法自适应地去调节
• no18：常见微服务分层架构，异构服务器负载均衡，方案二：动态权重
  • 1.如何标识服务的处理能力？(下游的处理能力是由调用方决定的)
  • 2.如何设计动态权重？
  • 对每一个微服务的连接使用一个权重来标识，这个权重决定分配给每个微服务请求的概率，获得相应连接的概率，当下游每成功处理一个请求的时候，就认为下游的微服务的处理能力足够，增加权重(缓慢)，当微服务超时处理一个请求的时候，就认为下游的处理能力，可能要跟不上了，权重就减少(快速)
  • 可把权重的范围设置为[0，100]之间，初始值设置为 60，
• no18：什么是过载保护？
  • 
  • 如果不对微服务实施过载保护，随着上游的负载越来越高，在微服务的处理能力范围内，每秒处理的请求是越来越高的
  • 但是达到一个负载的极限时，外部负载持续的增加，它的处理能力会掉底，瞬间降为 0，即「雪崩」
  • 
  • 如果实施了过载保护，那么随着外部负载的增加，处理能力到达一个 max 值后，会保持相对稳定的一个值，系统不会被完全压垮
• no18：如何实施过载保护？
  • 1.静态权重(粗暴，不优雅)
    • 给微服务的处理能力设置一个阈值，如果负载超过这个阈值，就将后续的请求全部抛弃
  • 2.动态权重
    • 1.连接表示服务，分值代表服务(连接)
    • 2.处理成功加小分，处理失败扣大分
    • 3.到达临界编译时，如有请求超时的时候，可判断快要处理不过来了，让它有请求处理失败的时候休息一会，再接下来 10 秒内不再给这个超时的服务器进行负载分配
    • 4.如果仍然连续地超时，可能判定这个服务器完全处理不过来了，如 fullGC，根据经验，fullGC 差不多一分钟之后能回过神，则一分钟后给它分配请求
    • 但如果整体负载超过了微服务集群的整体负载，最终还是要抛弃部分请求

20、服务化：连接池，高可用可扩展负载均衡都离不开他

• no20：微服务分层架构中，连接池的位置
  • 
• no20：高可用，故障转移，在连接池中是如何实现的？
  • 
  • 当有节点失效时，连接池重试也连接不上，则连接池会把失败的连接剔除出去
• no20：扩展性，服务发现，在连接池的实现
  • 1.自动载入新服务节点的配置
    • 方案一：监控配置文件，并重新载入
      • 具体实现可以是启动一个进程，监控文件变化，循环检测文件 md5是否变化，如果变化则读取新服务节点的配置
    • 方案二：配置中心回调，并重新载入
      • 每当调用方站点集群向配置中心注册了下游所依赖的微服务集群的配置，如果微服务集群的节点发生了变化配置中心会给调用方的站点集群进行回调，会将变化后的节点通知站点集群，再实施连接池自动增删节点
  • 2.动态连接池
• no20：负载均衡，连接池的实现的三个方案
  • 方案一：随机/轮询(同构服务器)
    • 
  • 方案二：静态权重法(异构服务器)
    • 
  • 方案二：动态权重法(异构服务器)
    •