腾讯微服务架构的发展趋势

腾讯微服务框架的产生
面对业务海量访问，腾讯开始采用微服务架构的思想，设计和实现一个通用的 统一应用框架平台，对业务提供涉及到开发、运维以及测试的一整套解决方案， 让开发更简单，运维更高效。
TARS产生 TARS弹性调度化
海量服务之道
过载保护 大系统小做 按set部署
TARS优化重构
TARS发展第一阶段
1
服与1务自0混动0合化%部运署营
2
服务混合部署：
1. 使用Docker方案将每个进程的运行环境和资源消耗隔离起来。 2. 服务部署、打包、发布等标准化. 3. 提高了部署效率，保证了交付质量，提升了资源利用率
弹性调度:
1.服务进程不再对机器有特殊要求，使得进程可以被部署到所有类型的 机器上，给弹性调度巨大的操作空间。 2.一个服务下的所有容器可以被规整为相同的规格，使得服务的流量调 度变得更加简单，简化了弹性调度的操作。
自动测试
代码管理
分布式数据访问
配套系统 API Gateway
分布式事务
服务治理
服务发…现… 配置管理Metrics监控
熔断
调用链
过载保护 消息队列
RPC 日志聚合
正式发布
Restful
10% 20% 30% 40% 50% 60%
完整的微服务体系是庞大复杂的
借助合适的微服务框架去逐步构建整个微服务体系是一条快捷途径
2000-2008年中国网民规模与增长率
2007-2008手机上网网民规模对比
用户产品规模急剧扩张
腾讯在2006-2007年接连推出了多个手机应用服务：手机QQ、超级QQ、手机腾讯网、手机QQ 游戏大厅、手机QQ浏览器、手机QQ空间、数十款WAP游戏应用，随着用户规模和产品规模的急 剧膨胀，各种各样的困难接踵而至。
智慧IT
腾讯微服务架构的发展趋势
技术创新，变革未来
• 海量服务与用户催生微服务框架
• 十年经验沉淀促技术产生价值 • 未来：微服务开发者生态共建
移动互联网浪潮
2008年6月底，中国网民数量达到2.53亿，中国互联网网民规模首次超过美国，跃居世界第一位。 截至2008年底，使用手机上网的网民达到1.176亿人，较2007年增长一倍多。接下来的几年，迎 来了一波移动互联网浪潮，手机上网成为网络接入的一个重要发展方式。
多语言带服务治理类 多种编程语言实现
腾讯自研微服务框架
TARS 是腾讯开源、基于 TARS 协议的高性能 RPC 框架，为开发和运维提供
了一体化的微服务治理方案。
多语言
C++ JAVA NodeJS PHP/Python
敏捷开发
快速构建 自动代码生成
持续集成 高扩展性
高可用
服务发现 容灾容错 智能调度 柔性熔断
伸缩性：服务可以方便的平行扩展。 管理：在web上就能对系统的服务进行部署、发布、上线、扩容、缩容等管 理操作。
TARS发展第二阶段
第二个阶段，框架优化重构的阶段。目的是解决框架性能和开发易用性的问题。
1
解1决发0性易0能用%和性开
2
性能：
1. 将仅支持单线程的收发包模式，改造成多线程收发包模式 2. 将框架内影响线程并发运行的粗粒度锁，改造成锁细粒度化或者无锁化 3. 数据交互尽量零拷贝
业务逻辑
业务逻辑集中，耦合性强，开发 维护成本高，服务模型多样化， 业务协议不统一
业务的多样性、复杂度、 爆发性增长的规模
代码质量
代码重复率高，性能、高可用性、 可扩展性等方面难以适应业务海 量访问发展趋势
运营管理
运维工具各异，部署管理混乱， 规范性差，管理能力薄弱
监控体系
运营数据缺失，监控维度不立体， 故障时分析和查找问题困难
高效运营
Devops
代码管理 代码编译 自动化测试 持续部署 灰度发布
OSS
服务注册/发现 负载均衡
服
熔断
服务配置
务
Metric监控
日志聚合 自定义监控 Set模型
治 理
分布式跟踪
自动区域感 知
92%
21%
31%
23%
19%
25%
30%
14%
14%
8%
0
制造行业
金融行业 互联网行业 交通物流行业 零售行业
半年一次 3-6个月更新一次 每个月都要跟新、升级
采用其他微服务开发框架
已经部分引入Spring Cloud 微服务开 发框架
正考虑往云原生（Cloud Native）架 构转
不考虑，全部基于weblogic、 WEBSPHERE等传统构架 0% 10% 20% 30% 40% 50% 60%
• 海量服务与用户催生微服务框架
• 十年经验沉淀促技术产生价值
• 未来：微服务开发者生态共建
微服务成为趋势
业务场景、用户习惯和行为在迅速变化，传统行业线上业务出现急速增长
63% 企业平均每月发布一次
51% 考虑转型，15%已经实施
100%
80% 60% 40% 20%
0%
65%
55%
52%
51%
开发易用性：
1. 对原来的同步调用方式，通过协程技术，不改变原来的同步编码方式， 对业务透明，只需通过配置开关，可将其实际执行变同步为异步 2.对于原来的异步调用方式，通过future/promise技术，让编码方式像 同步一样
TARS发展第三阶段
第三个阶段，框架弹性调度Docker化的阶段。目的是达到服务混合部署与自 动化运营的效果。
第一个阶段，框架产生的阶段。目的是做以微服务为基础的分布式架构。
1 2
微的1服分0务布0为式%基架础构
Leabharlann Baidu
3
4
5 6
IDL（接口定义语言）：统一不同语言的访问协议，二进制、可扩展、代码 自动生成、支持多平台。 RPC：支持同步、异步、单向调用。
高性能：框架提供10w/s以上的吞吐量。
容错：任何一台服务down掉不影响业务访问。
微服务框架现状
无服务治理类
专注于通信框架，RPC或消息队列模式， 部分框架支持多语言开发
支持服务治理，通过SideCar模式解决多语言问题，
ServiceMesh 目前处于发展成熟期
单语言带服务治理类 在通信框架的基础上支持服务治理能力，单 一编程语言实现，JAVA语言为主流
在通信框架的基础上支持服务治理能力，
企业转型微服务面临的挑战
微服务自身复杂度以及人才和经验的匮乏成为企业微服务化最大的挑战
缺少具备相关经验专家 不同部门目标不一致，可能引起组织冲突
缺乏专业人士和工具 行业的限制和监督
感觉技术不成熟，不想做小白鼠 业务上没需求
上手难，对微服务不理解 对微服务带来的复杂度有顾虑
0%
代码编译
DevOps
灰度发布