前隆科技微服务实践的那些事

微风

2019/03/24 发布于 技术 分类

文字内容
1. 前隆微服务实践的那些事 分享人 / 汤恒杰 @前隆科技
3. [ 自我介绍 ] l 汤恒杰 l 前隆科技架构团队负责人, 架构部经理 l 曾先后就职于 5173、携程、创过业 l 2017年加入前隆科技,工作内容主要聚焦于基 础架构与业务架构的演进,平台体系的建设、 实施与落地
4. • 公司介绍 • 实践之初我们遇到了什么问题 • 微服务当下实践的现状 • 实践过程中经历了遇到了什么问题,如何解决的 • 对未来的一些展望
5. 公司介绍 一家致力于推动消费和金融行业进入移动化、智能化的互联网科技公司。基于 人工智能、生物识别、大数据、云计算等技术,通过以多场景在线营销获客、 “人机对抗”风控技术支持、全流程IT系统解决方案为核心的服务体系,帮助 客户大幅提升运营效率,降低获客成本。
6. 先前的应用层框架 DubboX + SSM(Spring、SpringMVC、MyBatis)
7. 先前的应用架构 产线 公共 Service Service Service Service Service RabbitMQ RabbitMQ Service RabbitMQ 核心 Service Service Service Service
8. 先前的应用架构 重服务 问题排查定位困难 随心所欲的调中用 问题修复周期长 一做活动就挂一片 线上事故后知后觉
9. 先前部署交付构成 Docker + Dock Compose + Jekins
10. 先前服务部署交付方式 product release yum pkgs upload pkgs [VM] Images Repo yum Repo get service's pkg pull image Docker Dashboard [VM] [物理主机] 创建Docker 环境 [VM] 批量重启服 务 创建Docker 容器 Environment select 拷贝代码 Containers Jenkins 部署RPM包 检查中间件 yum install 检查服务 48C380G [VM] 8C60G Choose service SSH Meta DB get service meta Select branch Choose container Start Build
11. 业务阶段与项目特点 主营业务的快速发展 新业务的持续尝试与试错 项目迭代频次快 项目并行度高
12. 资源成本消耗已成为不可承受之痛 业务领域A 业务领域B 业务领域 N 项目1 一组业务领域A的全系统 一组业务领域B的全系统 一组业务领域N的全系统 项目2 一组业务领域A的全系统 一组业务领域B的全系统 一组业务领域N的全系统 ...... ...... ...... ...... 项目N 一组业务领域A的全系统 一组业务领域B的全系统 整个全流程涉及 400+ 应用服务 一组业务领域N的全系统 MAX(Project) = 20 8000+ Containers 120+ 30+ VM Nodes Phy Machines 300W+ RMB
13. 突出的主要矛盾 业务监控缺失,业务先于研发先发现问题 突发流量下系统异常,产生雪崩效应,业务不可用 线上问题定位排查困难,问题解决时间久,严重影响产品体验 现行的交付方式导致资源急剧升高,成本居高不下 高并行项目测试对环境的保鲜及稳定性要求,OPS已力不从心
14. 问题归类 基础架构不完善 交付方式的不合理 钱的问题
15. 目前的微服务架构 http/https/mqtt 路由管理 基础设施监控 API Gateway 安全管控 版本管理 流控管理 RMQ消息治理 REST rpc rpc rpc Kafka消息治理 SpringBoot SpringBoot Cacti rpc SpringBoot 产品业务 Zabbix 统一配置中心 rpc rpc dubbo rpc dubbo rpc 日志中心 dubbo rpc QL-APM 核心业务 自动化测试 rpc rpc 自动化构建 度量平台 SpringBoot rpc SpringBoot SpringBoot Synthetics 服务治理 rpc 自动化部署 业务预警平台 rpc 任务调度中心 ... rpc 自动化运维
16. 对标SpringCloud 功能 Spring Cloud DubboX 前隆科技自研 服务注册中心 Spring Cloud Netflix Eureka Zookeeper ✔ 服务调用方式 REST API RPC/REST API ✔ 服务网关 Spring Cloud Netflix Zuul ✘ 统一网关 熔断器 Spring Cloud Netflix Hystrix 不完善 Hystrix For Dubbo 分布式配置 Spring Cloud Config ✘ 统一配置中心 服务跟踪 Spring Cloud Sleuth ✘ QL-APM (基于sky-walking) 消息总线 Spring Cloud Bus ✘ Fx-Component-MsgBus 批量任务 Spring Cloud Task ✘ 任务调度中心
17. 平台支撑与保障能力 灵活,限制你的只有想象力 定制,按需迭代,想怎么玩怎么玩 可控,出了坑,能快速搞了定 自 研 苦,社区红利享不到,要用自己造 累,消耗大量的时间与精力 痛,人胖了,腰废了,头发秃顶了
18. 服务治理 服务治理平台 Application SgpClient 元数据管理 服务审核 接口文档与 调试 依赖分析 状态监控 限流/降级/ 熔断 健康监控 调用链路与 统计 Mysql Dubbo Elastic Search
19. 统一配置中心 TCP 推拉结合 Zoo keeper Client SLB Client REST Portal SLB SLB REST 调用 http http ConfigServer Config DB
20. 日志中心 consume write Application SLB LogAgent detail data Consumer Elastic Search Kafka consume Aggregation Kafka Streams Dashboard SLB LogService query summary data
21. 现在的交付简化流程 禅道 GitLab Pull Jenkins 自动化运维平台 Yum Repo pkg CMDB Trigger get yum pkg Harbor 持 续 交 付 发布工单 状态通知 notify 通知中心 容器创建 冒烟测试 auto test 自动化回归测试平台 拉取代码编译部署 点火与健康检查 Pod Pod Container Container Pod Pod Container Container Pod Pod Container Container install check n s
22. 现在的kubernetes部署架构 K8s Node Cluster Node kube-porxy kubelet kubelet ........... kube-porxy LB-Active LB-Standby keepalived keepalived HA kube-porxy Nginx kubelet Nginx Master calico etcd api server kube-porxy controller manger scheduler manger kubelet k8s etcd api server kube-porxy controller manger scheduler manger kubelet k8s etcd Master K8s Master Cluster Master Calico calico etcd kubelet Node NFS calico etcd kube-porxy Node mount Node VIP api server kube-porxy controller manger scheduler manger kubelet k8s etcd
23. 实施中不同角色的诉求 [开发] 发布能不能快点, 环境能不能好用点? [测试] 环境要稳定,并且能不能随时保鲜? [OPS] 别整那么多套环境,消停消停? [领导] 能不能别这么浪费,省点钱?
24. 解决方案“葛朗台” 起了一个很有“特色”名字 “葛朗台” l 省时 l 省力 l 省钱
25. 问题的元凶 硬件资源 消耗越来 越高 >90%都 是多余的 人力已不 是解决问 题的关键 OPS人力 已经无法 支撑 按套交付 项目越 多,越不 可能消停 保鲜是一 件很坚难 的事 太过分 散,质量 无法保证 交付了太 多,自然 响应就慢
26. 需求与保障的拐点 项目需求 保障与支持能力 保 障 与 支 持 能 力 项目需求
27. 解决问题的办法 按套交付 按需交付
28. 按需交付的方式与期望的结果 BASE (与生产同步 的稳定环境) P1 非BASE (功能测试交 付环境) H5 Java-Web Java-Dubbo-C Java-Dubbo-P Java-MQ-P Java-MQ-C Java-Web A B C D E F G A1 B1 D3 P3 P4 E2 C2 P2 A4 E3 G4
29. 容器分配规则 按需交付 BASE Pod Container Pod Container Service1 Service2 Pod Pod Pod Container Service3 ...... Pod Container ServiceN service = application name namespace = sat-base (与生产同步 的稳定环境) Container Service1 Container Service2 非BASE (功能测试交 付环境) Pod Container Service1 Pod Container Service2 (service1, service2) service = application name (sat-10001) namespace = sat-{work-order number} usertag = project name (趣花分期-改版) Pod Container Service8 service = application name (service1, service2, service8) namespace = sat-{work-order number} usertag = project name (sat-10002) (风控模型-3.0)
30. 问题总是很多
31. 按需交付后的系列问题 核心问题: l 如何保证请求能请求到按需交付的服务 l 服务间的调用如何满足只能调用按需交付的服务 l 如何保证消息的正确消费,只能被已交付的服务消费 l 如何保证对配置依赖冲突,做到互不影响 l 如何做到按需实时保鲜,同时不影响正在测试的项目
32. 问题场景事例 场景 Base1 Sce1 Sce2 非Base Sce3 服务 H5 A HTTP HTTP HTTP B C E D F B1 B2 默认Base中只能调用Base 如何保证A->B1还不是到B RPC RPC 如何保证A->B2还不是到B1,B同时 B2只能调用到C2 C2 C3 AMQP AMQP Sce4 Sce5 问题 RPC C5 如何保证B只能调用到C3, 同时C3 发送的消息只能被D3消费 D3 D4 RPC E4 AMQP F4 如何保证C发送的消息只能被D3消 费,D3只能调到E4,E3发送的消息 只能被F4消费 如何保证C , C2 , C3 ,C5 对某个共 用的配置依赖不产生冲突
33. 保鲜问题场景事例 场景 Base1 服务 H5 A HTTP B C 问题 E D F 默认Base中只能调用Base V1 非Base Sce1 C1 依赖一个相对较旧 D 的版本 Sce2 C2 依如何保证对 C2 进行版本保鲜时 不影响当下验证中的其它的链路 Sce2 3 C3 D V2 D V2 依如何保证对 C3 进行版本保鲜时 不影响当下验证中的其它的链路
34. 问题具体化-Dubbo 服务注册中心 2. 订阅 1. 注册 3. 通知 服务提供者 4. 调用 Random - 随机 服务消费者 Service A (192.168.1.1 : 8080) (192.168.0.1 : 8080) (192.168.1.2 : 8080) (192.168.0.2 : 8080) (192.168.1.3 : 8080) (192.168.0.3 : 8080)
35. 问题具体化-RabbitMQ Connection Channel Connection Chann 1 Producer el Chann 2 Producer el Channel Exchange Queue Connection Channel Broker Connection Channel Consumer4 Provider2 Chann 1 Consumer el Chann 1 Consumer el Chann 1 Consumer el Chann 4 Consumer el
36. 问题具体化-Kafka
37. 问题具体化-配置中心 同一个服务不同的使用方想使用不同的配置项
38. 解决问题的办法 核心思路: l 标记请求,指定路由 - 谁发起的请求,只会命中指定的服务结点,指谁调谁 l 路由信息上下文传递 - 请求标识会传递,包括所有的调用方式 l 配置 - 隔离 - 参数配置依赖基于请求标记隔离,不同的人可以用不同的配置项 l 保鲜 - 多版本冗余 - 路由冗余隔离,基于验收状态,智能切换
39. 指定路由原理剖析 Route Config Center Specify Route Keep Refresh Config Isolation Link Circuit Monitor Help Event Report Agent Agent Agent Agent Agent Agent RouteCode RouteCode RouteCode RouteCode RouteCode RouteCode CxtManger Header Dispatcher Servlet doService SpringMVC CxtManger Header Abstract HttpClient doExecute HttpClient CxtManger CxtManger CxtManger RpcContext MsgProp. Header Header/Msg MsgListener Container Kafka Template Cache Manager basicPublish sendSync getActiveMap basicConsume receiveMsg getStaticMap Fx RabbitMQ Kafka CfgCenter SgpScript Router route Sgp-Client (dubbo) CxtManger CacheManger2 ...
40. 路由链路逻辑架构
41. 服务无感知保鲜 自动化运维平台 CMDB CD SAT FAT Pod Container Service1 PRO Yum Repo sat-base-2 Pod Container Service2 Pod V1 Container Service2 SAT-nobase SAT-base (1/2) V1 保鲜优先 / 历史版本优先 Pod 保鲜 Container Service3 Pod Pod V2 Container Service3 Jenkins sat-nobase Pod Container Service2 Pod Container Service3 V2 Container Service4 ....... sat-base
42. 路由链路推演 BASE (与生产同步 的稳定环境) P1 非BASE (功能测试交 付环境) H5 Java-Web Java-Dubbo-C Java-Dubbo-P Java-MQ-P Java-MQ-C Java-Web A B C D E F G A1 B1 D3 P3 P4 P1 -> (A1,B1) C2 P2 A4 指定路由 配置中心 E2 P2 -> (C2,E2) E3 P3 -> (D3,E3) G4 P4 -> (A4,G4)
43. 路由配置中心
44. “葛朗台”所带来的成果 释放OPS专职于环境的人力 降低资源成本 5人 60% 硬件成本 交付响应速度 > 30% 测试与验收效率 >20%
45. 未来展望 积极的拥抱变化 再深一步整合资源,提高效率 业务驱动向技术创新驱动的蜕变
46. 完成调查问卷 有神秘礼品相送 关注前隆科技 获取更多资讯