微服务

定义

微服务，又称微服务架构，是一种架构风格，它将应用程序构建为以业务领域 为模型的小型自治服务集合。

特点和优点

  • 解耦—系统内的服务很大程度上是分离的。因此，整个应用程序可以轻松 构建，更改和扩展,这样可以最大程度避免代码堆积难以维护,极大降低程序耦合度
  • 组件化—微服务被视为可以轻松更换和升级的独立组件
  • 业务能力—微服务非常简单，专注于单一功能
  • 自治—开发人员和团队可以彼此独立工作，从而提高速度
  • 持续交付—通过软件创建，测试和批准的系统自动化，允许频繁发布软件
  • 责任—微服务不关注应用程序作为项目。相反，他们将应用程序视为他们 负责的产品
  • 分散治理—重点是使用正确的工具来做正确的工作。这意味着没有标准化 模式或任何技术模式。开发人员可以自由选择最有用的工具来解决他们的 问题
  • 敏捷—微服务支持敏捷开发。任何新功能都可以快速开发并再次丢弃
  • 接口的定义和实现是分离的,完全不需要等待实现,根据接口就可以进行完整的编程,符合设计模式 > 依赖倒转原则
  1. 耦合度降低,不同模块开发代码隔离化,业务独立设计,更加灵活,泳道实现的基础
  2. 接口实现分离,提高开发效率
  3. 风险隔离,耽搁服务不影响整体,更好做熔断和限流
  4. 扩展简单,可以按照不同微服务的负载独立化扩展,资源更高效

缺点

  • 不可避免的因为rpc调用使得请求的时间被延长,延迟变长
  • 链路监控变得复杂和治理难度增加
  • 分布式系统带来的问题,CAP定理

常见负载均衡策略

  • 简单随机
  • 加权随机
  • 简单轮询
  • 简单加权轮询
  • 平滑加权轮询
  • 一致性哈希
  • 最少活跃数

coa

  1. 通过etcd的强一致性保证分布式结构下请求打到正确的地方
  2. 负载均衡以及服务监控状态下线隔离都是通过client实现(coa-client),client自己通过负载均衡选择需要连接的节点
  3. 如果没有client监控以及这个微服务没有其他的实例,那么租约过期没有续约会直接被删除而不会加到隔离的文件夹(当然自己也会监听其他的同类型的微服务实例)

具体流程

service

  • service首先定义好interface(相当于接口定义),使用脚本生成一个interface仓库作为sdk
  • 面向接口编程,首先service先在etcd注册service_url,并通过心跳保活维持online租约val为自己的端口号和ip(需要内网,因为无法自己获取外网ip),一旦服务失效心跳过期,online失效,如果有监控这个service_url的微服务(比如客户端),会把这个key放到隔离区

client

  • client调用的时候,将所有的online下的key获取,进行负载均衡,计算这个请求给哪个受理,将参数格式化后通过msgpkg协议传输,等待相应结果并返回

QA

coa和go-micro,grpc框架有什么区别

  1. coa使用go的反射特性,使用redis-msgpack序列化,和其他使用protobuf不一样
  2. coa只支持go的,其他可以跨语言支持,因此coa框架更加简洁,不会需要 .pb文件,但是扩展性(插件的开发)和兼容性比较差
  3. micro是一个微服务系统,提供服务的注册与发现的功能,grpc是rpc一个数据传输的方法,是一个rpc框架,coa两者都有,但是更加接近于grpc

缺点

  • 强依赖etcd,一旦etcd出问题,所有的rpc都会失败,中心化严重(虽然etcd可以集群部署,但是一旦出现半数崩溃,系统就直接崩溃)
  • 服务一旦被隔离,没有很好的解决办法接触隔离,只能人工解除隔离,这样如果出现区域的网络波动导致大面积隔离就会崩溃

优点

  • 每次rpc服务发现的都是节点的最新状态,消息滞后的现象出现少
  • 不需要中心服务routesvr,中心直接通过etcd实现,简化流程思想
  • 小而美的微服务框架,但是可用性不够高,容灾能力差

svrkit

服务发现

  • 使用很特殊的方式进行,每台机器会部署zkagent,这里采用主动pull模式，zkagent会定时从本IDC的zkagentproxy拉取任务，更新本地配置文件。但是每个server部署还是回向中心的zookeeper,报备更新路由信息
  • 机器上所有的发现服务都是直接在本地文件中获取,不会从中心的zookeeper中获取,更加快捷
  • 每次rpc调用都会进行上报和监控到routesvr,使得如果出现多次不可用的现象就会进行屏蔽机器

优点

  • 极致的可用性,提供中心化的服务发现的服务，的确实现简单，但有巨大单点风险，一旦服务挂了，所有的服务都不可用了。而svrkit 的服务发现是去中心化的，无论是哪个角色: route svr, zookeeper, zkagent, route report thread 挂了，只要本地路由文件没有被删除，都不会影响调用下游服务
  • 高容灾能力,及时出现网络波动也能很快恢复正常

缺点

  • 实时性不够好,如果服务出现问题,需要足够时间才能发现出问题,然后还需要agent主动pull,因此实时性不够好
  • 这个需要大规模系统和完成成熟的配套措施才能解决,不然很容易出问题,只适合大公司使用

服务屏蔽

  1. mmlbapi 提供给Svrkit 框架使用，用于收集统计信息和检查路由是否可访问
  2. mmlbagent是常驻进程, 负责当前机器上所有模块的访问结果统计数据收集和生成屏蔽策略，并将策略结果和统计数据及mmlbagent的运行情况上报到mmlbcenter.用于判断路由是否故障的统计数据包含：网络连接失败，读失败，写失败，逻辑错误等等。
  3. mmlbcenter 收集现网所有的mmlbagent的上报, 进行数据合并和入库存储.
  • 屏蔽周期：当某个服务实例被故障判断策略确定为异常时，会将该实例摘取掉, mmlbapi 在做路由选择时会忽略掉异常节点
  • 探测周期：我们肯定在服务实例恢复之后，就解除屏蔽，但我们不知道服务实例什么时候恢复。因此在屏蔽时，会计算一个故障屏蔽时长，mmlbagent会定期检查屏蔽策略是否超时，需要进行恢复探测。若该路由被故障恢复策略确定为正常时，则解除屏蔽该实例，恢复其为正常；否则则继续屏蔽（Netflix 的Hystrix 熔断组件也提供了类似的熔断-恢复机制）

框架实现(Phxrpc)

过载保护

  • 开一个现成一段时间检查一次
  • 检查平均响应耗时是不是比设置的大,如果是就调整拒绝率
  • 每个请求过来之后随机根据拒绝率直接拒绝

特点

  • 没有任何服务注册发现,服务发现全靠client的配置文件
  • 一大堆缓冲buf削峰
  • 相当于包工头机进行层层分发任务工作
  • 参考 https://cloud.tencent.com/developer/article/1396622