以腾讯开源的Tars为例谈谈微服务

软件行业发展到现在，很多人都曾被大而全的产品折腾得苦不堪言。因此，近些年云原生(Cloud Native)的概念也渐渐扩散开来。作为云原生基础设施之一的"微服务"也备受瞩目。那什么是微服务，微服务又解决了哪些问题呢？今天小编以腾讯的开源微服务框架Tars为例，跟大家聊聊微服务。

现实中的问题

在微服务以前，存在两种情况：

• 单体架构：一个系统包含所有功能(大而全)；
• 多体架构：多个系统由多个不同团队开发，开发标准(SDK、代码风格、验收标准等)各不相同。

单体架构的问题

1. 单体架构中的系统代码量过大，容易吓跑新的开发人员;
2. 超载IDE，代码体量大，IDE运行加载慢，影响开发效率;
3. 持续部署困难，牵一发而动全身，无法进行快速迭代和频繁部署;
4. 扩展困难，不能通过简单地增加实例的方法应对性能瓶颈，无法针对IO密集型、CPU密集型或内存密集型的业务进行资源分配;
5. 扩展障碍，功能过多不可避免地由多人负责，人数越多，协调开发进度，更新产品越困难；
6. 被原有技术栈绑架，单体架构强迫你必须在原有的技术栈上进行新功能开发，而与行业内新的语言和新的技术无缘。
   
   既然单体架构有问题，是不是我简单的把一个系统拆分成多个系统就行了呢？那我们来看多体架构。

多体架构的问题

从开发的角度：

1. 不同的产品，业务模型多样化，开发语言不同；
2. 不同产品之间的业务通信协议不统一，对接不同产品时的学习成本大;
3. 容错、容灾、可扩展性等质量指标参差不齐，导致开发人员不能很好的聚焦于业务本身;

从维护角度：

1. 不同业务之间的部署工具不同，运维人员花费大量时间在安装调试系统环境上;
2. 部署管理混乱，不同业务之间的配置文件互相依赖，需要运维人员完全理解产品所有业务逻辑;
3. 产品周期长，转测时需要协调各个组件的进度，开发团队的整体运转效率偏低;

监控能力薄弱，出问题之后需要用户投诉才能发现问题。

全栈的问题

你可能会说，这都是大系统存在的问题，我一全栈的工程师，前端用Javascript后端用Nodejs，业务自己设计不和你们掺和在一起，总没问题了吧。

但是你会直面老大的灵魂拷问：

1. 你经过压力测试了么？
2. 这个请求耗时太高了，不能上线；
3. 能不能不要每次修改配置文件和缓存数据都重启服务？
4. 服务异常能及时告警么？
5. 需要有灰度逻辑啊，不能每次都在线上环境改啊；
6. 线上出问题，你能及时定位到么？

此时你的心情一定是这样的：

微服务框架—Tars

如果你一直被上面这些问题困扰，那么你可能就需要用到微服务了。
微服务是一种服务治理的思路，在业界没有具体的定义，各家企业有自己的微服务标准，下面以腾讯开源的Tars为例来介绍微服务。

Tars是什么

Tars是将腾讯内部使用的微服务架构TAF（Total Application Framework）多年的实践成果总结而成的开源项目。

有哪些成果

设计思想

Tars的目的：
让开发人员更加聚焦于业务逻辑本身;
让运维人员只需关注日常服务部署、发布、配置、监控、调度管理等操作。

从上图中可以看出，微服务框架将容灾、负载、监控、部署、协议等通用功能抽离出来开放给开发人员使用, 既能让开发人员更聚焦于业务本身，又能让运维人员从业务逻辑中解脱出来。

通常好的微服务，有以下特点：

• 可扩展好：业务之间用接口通信
• 易用性好：公共组件和通信框架省去很多代码，支持RPC调用
• 支持多语言：让开发人员有更大的发挥空间
• 性能高：异步通信，资源按需分配
• 分布式部署：开发人员不用关心负载均衡、备份容灾等问题

整体架构

Web管理系统： 在Web上可以看到服务运行的各种实时数据情况，以及对服务进行发布、启停、部署等操作；

Registry（路由+管理服务）： 提供服务节点的地址查询、发布、启停、管理等操作，以及对服务上报心跳的管理，通过它实现服务的注册与发现；

Patch（发布管理）： 提供服务的发布功能；

Config（配置中心）： 提供服务配置文件的统一管理功能；

Log（远程日志）： 提供服务打日志到远程的功能；

Stat（调用统计）： 统计业务服务上报的各种调用信息，比如总流量、平均耗时、超时率等，以便对服务出现异常时进行告警；

Property（业务属性）： 统计业务自定义上报的属性信息，比如内存使用大小、队列大小、cache命中率等，以便对服务出现异常时进行告警；

Notify（异常信息）： 统计业务上报的各种异常信息，比如服务状态变跟信息、访问db失败信息等，以便对服务出现异常时进行告警；

服务交互流程图

框架服务在整个系统中运行时，服务之间的交互分：

• 业务服务之间的交互;
• 业务服务与框架基础服务之间的交互。

服务发布流程： 在Web系统上传server的发布包到patch，上传成功后，在web上提交发布server请求，由registry服务传达到node，然后node拉取server的发布包到本地，拉起server服务。

管理命令流程： Web系统上的可以提交管理server服务命令请求，由registry服务传达到node服务，然后由node向server发送管理命令。

心跳上报流程： server服务运行后，会定期上报心跳到node，node然后把服务心跳信息上报到registry服务，由registry进行统一管理。

信息上报流程： server服务运行后，会定期上报统计信息到stat，打印远程日志到log，定期上报属性信息到property、上报异常信息到notify、从config拉取服务配置信息。

Client访问Server流程： client可以通过server的对象名Obj间接访问server，Client会从registry上拉取server的路由信息（如ip、port信息），然后根据具体的业务特性（同步或者异步，tcp或者udp方式）访问server(当然client也可以通过ip/port直接访问server)。

微服务不是银弹

虽然微服务有诸多好处，但也不是万能的。

很多企业在实践中，也发现了以下问题：

1. 软件架构本身受限于企业的组织架构；(即康威定律，如上图，公司的组织架构就决定了公司的软件架构)
2. 把旧的业务迁移到微服务上工作量并不小，而且还有很多坑要踩;
3. 通常小型企业相比于自己搭建微服务，并不会比用第三方服务更划算;
4. 使用微服务必须遵循微服务的规范，并不是所有的业务都适合。(比如：所有请求必须是异步的，要在业务层面考虑到有可能相同客户端的多个请求可能落在不同服务器的情况，最好读写分离等)

---

如果您对微服务感兴趣，请扫描下方二维码，关注“麻辣软硬件”公众号，小编后续将为您介绍Tars的安装和使用。