开发易用性问题：随着业务的发展，业务的服务模块越来越多，服务模块之间交互的关系越来越复杂，线上业务服务为了保证服务的稳定性，一般采用异步Callback方式进行服务交互，而异步Callback方式的代码逻辑分散，阅读和维护起来比较困难。为了让开发编写代码更加简单，我们提供了协程和future/promise两种编码方式。对原来的同步调用方式，atv，通过协程技术，不改变原来的同步编码方式，对业务透明，只需通过配置开关，可将其实际执行变同步为异步；对于原来的异步调用方式，通过future/promise技术，让编码方式像同步一样。

第三个阶段，框架弹性调度Docker化的阶段。目的是达到服务混合部署与自动化运营的效果。

服务混合部署问题：这个时期，使用tars的机器规模达到了1w多台，服务进程数量达到了6w个，而其中小服务比例很高，80%的进程CPU峰值小于1核，这中间还有75%的进程连0.1核都用不到。为了提高资源利用率，必须要将服务混合部署。但是进程依赖的运行环境差异大，不同进程的依赖经常存在冲突，导致混合部署难度很大。

即便没有环境冲突，各个服务进程部署到一台机器上之后，经常出现资源竞争，影响服务质量的问题。于是我们通过使用Docker方案将每个进程的运行环境和资源消耗隔离起来。服务部署、打包、发布等标准化，这样提高了部署效率，保证了交付质量，提升了资源利用率。

弹性调度问题：通过使用Docker技术，服务进程不再对机器有特殊要求，使得进程可以被部署到所有类型的机器上，给弹性调度巨大的操作空间。同时，通过Docker技术，一个服务下的所有容器可以被规整为相同的规格，使得服务的流量调度变得更加简单，简化了弹性调度的操作。

　　3当前Tars微服务架构设计

Tars微服务架构的主要设计思想是以开发与运营之间DO分离为原则，采用分层思想，将各个层次之间相互解耦或者松耦合。

最底的协议层：设计思路是将业务网络通信的协议进行统一，以IDL(接口定义语言)的方式，开发支持多平台、可扩展、协议代码自动生成的统一协议。在开发过程中，开发人员只需要关注通讯的协议字段的内容，不需要关注其实现的细节。

中间的公共库、通讯框架、平台层：设计思路是让业务开发更加聚焦业务逻辑的本身。因此，从使用者的角度出发，封装了大量日常开发过程中经常使用的公共库代码和远程过程调用RPC，让开发使用更简单方便；从框架本身的角度出发，做到高稳定性、高可用性、高性能，这样才能让业务服务运营更加放心；从分布式平台的角度出发，解决服务运营过程中，遇到的容错、负载均衡、容量管理、就近接入、灰度发布等问题，让平台更加强大。

最上面的运营层，设计思路是让运维只需要关注日常的服务部署、发布、配置、监控、调度管理等操作，运维更高效。

分层的思想主要来自于多年海量分布式服务下的实践、总结和提炼。

一方面，希望框架提供的功能和特性更全面、更完整，解决开发和运维面对的一些共性问题，比如涉及到分布式系统的高可用、容错容灾等，涉及运营操作的服务部署、发布、配置、监控、日志等，让业务开发更加聚焦其业务本身的逻辑开发，提高开发效率，同时让运维管理更加简单化、规范化、流程化，提升运维效率；

另一方面，希望框架支持的能力更灵活，业务可以使用整个系统中的某些部分或者整个功能和特性，这样业务在接入使用时，可以自主选择，减少改造成本，满足不同业务不同场景的需求。比如：终端与后端需要交互的业务，可以只使用统一的协议层进行通信；已有自身通信协议的业务，可以使用支持自定义协议的通信框架层等；对使用其他框架开发服务的业务，可以使用平台层提供的服务管理、监控等功能特性。

　　4Tars技术概览

　　（一）架构拓扑图

整体架构的拓扑图主要分为两个个部分：服务节点与公共框架节点。

1. 服务节点: