唯品会微服务框架学习笔记

  在ArchSummit深圳2019会议上，有幸参加了杨钦民架构师对唯品会微服务的分享，唯品会是对服务化走得比较彻底的公司，坚持微服务框架纯自研和彻底落地，所以在微服务问题域积累了非常多实践经验，目前也跟着业内趋势正在做微服务中台，以及整合k8s云平台和探索Service Mesh架构。

  这里简单整理下参会的学习笔记：

后台架构演进

• 单体架构：采用LAMP，基于单DB功能耦合
• 垂直应用架构：单体应用按业务垂直拆分
• 微服务架构（康威定律）：业务解耦、技术异构、独立维护、提升研发效率、有效隔离故障

微服务问题域

• 服务描述：XML（Dubbo/Spring）、IDL（Thrift/Grpc）
• 服务框架：协议（Http/Tcp/Udp）、传输（同步/异步）、序列化（Json/Pb）
• 服务发布/订阅：Registry（类zk，注册/心跳/订阅/变更）、Client、Service
• 服务路由：灰度、AB、流控、IDC选择
• 负载均衡：随机、轮询、最少活跃、一致性Hash
• 服务超时/重试：关注超时时间/重试次数设置，提高请求成功率
• 服务熔断：熔断器，open/closed/half-open（请求探测）状态转化
• 服务限流：从上到下，域限流->IP/ID限流->接口限流
• 服务降级：自动降级，开关降级，动态配置降级。如过载后对非核心路径暂停访问
• 服务追踪：基于谷歌Dapper，关注traceid/spanid
• 服务监控：系统/接口级别自动埋点上报，如最大QPS/总QPS/成功率/响应时间等

微服务组件选型

• 微服务框架：关注扩展性、跨语言和灵活的通讯协议
• 注册中心：关注高可用、数据一致性、多IDC部署，对比Eureka、zk、consul、etcd
• 配置中心：关注生效及时性、多IDC部署、易用性，对比Apollo、Disconf、SpringCloudConfig
• 熔断器：关注降级策略、隔离策略、流控策略、轻量级但高性能，对比Sentinel、Hystrix
• 全链路监控：关注多语言支持、代码侵略性、调用统计，对比zipkin、Pinpoint、SkyWalking、CAT

微服务面临挑战

• 分布式事务CAP原理：C一致性/A可用性/P分区容忍性，关于AP架构和CP架构的权衡
• 分布式事务BASE原理：基本可用/柔性状态/最终一致性，对AP方案的补充
• 分布式事务X/OpenXA协议：XA协议描述TM于RM的接口，允许一个分布式事务访问多个资源
• 2PC事务模型：两阶段提交，实现在DB资源层
• TCC事务模型：Try-Confirm-Cancel，实现在服务层
• 高性能全局事务GTSFeacar：基于2PC事务，无序开发人员实现正向补偿和回滚，减少业务代码入侵
• 分布式事务消息：基于2PC事务的消息投递，关注半消息、消息回查、消息回滚

唯品会微服务基础中台 Venus

• 服务框架：RPC框架、API网关、秒级监控、全链路跟踪、注册中心、服务治理
• 基础中间件：配置中心、任务调度、统一检索平台、消息队列、中央文档系统、数据服务平台

唯品会基于k8s云平台 Noah

• 镜像存储分发：基于Harbor（开源镜像仓库）定制化
• 容器编排：关注Node选择（CPU/内存，跨机器/机架）和高可用保证（HealthCheck探测）
• 自动扩缩容：基于K8s的HPA算法自研（核心还是CPU利用率）
• 金丝雀发布：下发发布指令，新起容器控制灰度权重

对于ServiceMesh架构探索

• 微服务架构痛点：嵌入式SDK，业务团队维护难，多语言研发成本，技术学习成本高
• 网格服务特性：基础设施层、可靠消息传递、轻量级网络代理、对应用透明
• 网格服务优势：为云原生而生、框架可演进、支持多语言、降级技术门栏、加速产品交互
• 业内ServiceMesh产品：Linkerd、Envoy、istio（最火）、Conduit、SOFAMesh（阿里）、Mesher（华为）