拥抱 TARS：构建 PHP 微服务生态 - OSCHINA

拥抱 TARS：构建 PHP 微服务生态

诞生于 2014 年的“微服务架构”，其思想经由 Martin Fowler 阐述后，在近几年持续受到重视，理论与相关实践都不断发展，目前谈架构必定会言及微服务架构。

伴随着微服务架构的快速发展，各种开发语言各种类型的微服务开发框架陆续出现，在近日举办的 PHPCon 大会上，来自开源微服务框架 TARS 核心开发组的梁晨，为开发者分享了 TARS-PHP 在 TARS 构建微服务生态中扮演的角色。梁晨同时也是 TARS-PHP 项目的主要负责人，以下是本次演讲全程的整理。

大家好，接下来 45 分钟的时间，我想跟大家聊聊 TARS 作为微服务平台本身有什么优势，同时也想让大家看到，TARS-PHP 核心开发组在这一年中，不断演进 TARS-PHP，将其融入 PHP 生态的努力，看看这对整个 TARS 微服务生态有些什么意义。

从近年来的业界架构演进来看，微服务已经逐渐成为趋势。从这张图可以看到，在不同的行业，发布服务的时间间隔各不相同，互联网行业每周发布的占比最高，但是其它行业也有逐渐赶上的趋势。

我们可以看到具体的发布数据，63%的企业平均每月发布一次。怎么将系统转到微服务架构上呢？现在有很多选择，接近 10% 的人选择 Dubbo 这样的原生框架，接近 50% 的人选择云原生架构，同时也有 30% 左右的人基于 Weblogic WEBSPHERE 等架构。而在这其中，51% 考虑转型，15% 已经实施。

从这些数据中我们可以看得出来微服务架构当前逐渐成为主流。

伴随着微服务架构的这种快速发展节奏，各种开发语言各种类型的微服务开发框架相继出现，我们分析了一下当前各家使用微服务框架的情况，可以看到主要分为四种模式：

• 无服务治理类：gRPC、brpc 为代表

• 单语言带服务治理类：Dubbo、Spring Cloud 为代表，主要适用于 Java 语言

• 多语言带服务治理类：TARS

• Service Mesh：SideCar 模式，仍在发展成熟期

这其中，TARS 在通信框架的基础上支持服务治理能力，同时支持多种编程语言，算是比较另类的选择。讲到这里，我们可以来看看它具体支持怎样的治理能力，在此之前，先了解一下微服务架构是怎样的。

从微服务整体架构上看，它主要分为：接入层、网关层、业务服务层、支持服务层和基础设施层。除此之外，非常重要而又容易被忽略的还有：微服务开发框架、持续交付流水线、端到端工具链、工程实践与规范这些构成整个微服务架构体系的部分，它们都在微服务的架构中发挥着非常重要的作用。  

TARS 整体可以分为运营、平台、通信框架、公共组件与统一协议几个大块，用于支持上述微服务架构层次。

简单来讲，运营平台上，TARS 可以支持不同语言服务的管理和运营，同时也支持页面级别服务的创建和发布；而在公共组件上，TARS 提供了非常多强大的公共组件来负责不同的功能，包括日志组件、监控组件、主控组件与配置组件等；统一协议方面，TARS 本身自带的二进制协议，非常适合高性能的场景，首先这个协议语言无关，自带接口描述，同时还有工具进行代码转换，可以大大提高开发效率。

聚焦到 TARS-PHP 上，作为Tars在PHP语言的解决方案，设计的时候主要考虑如下四个方面：

• 功能完善：对标现有 C++、Java 与 NodeJS 体系功能

• 灵活：论灵活，谁与 PHP 争锋？

• 轻量：用最轻量的设计，点到即止，即插即用

• 高效：插上 Swoole 协程的翅膀，不得不飞

整个框架主要分为四个部分：

• TARS-CLIENT

• TARS-SERVER

• TARS-EXT 扩展

• 代码生成工具

在过去的一年中，TARS-PHP 主要在丰富现有功能、构建更加开放的体系、引入 DevOps 的效率、更好地服务社区四个方面发力。

从 TARS-SERVER 功能层面来讲，TARS-PHP 新增了 WebSocket Server 和 PB SERVER，使得现在一个服务模板，能够实现多达五种不同的服务。

通过使用 WebSocket Server，用户可以有效扩展 Swoole 功能，它支持多个端口、自定义命令和非常灵活化的 FD 存储。

PB Server 构建了一个 gRPC 服务，这个服务部署在 TARS 平台上，参与 TARS 平台寻址，受 TARS 平台管理。这个服务使用 gRPC on Http/2 作为网络通讯协议，使用 Protobuf 作为编码协议，可以和其它 PB Client 协同工作。

在开发效率上，我们也针对 PB Client 做了优化，开发者同样可以通过我们提供的代码自动化生产工具，节约开发时间。

在 TARS-PHP 与平台更好地结合方面，我们实现了针对 PHP 服务的专有特性监控，它可以监控 Swoole 的 worker 数量、TIME_WAIT 等网络状态个数与 Swoole 中每个 worker 占用的内存情况等数据，让开发者更了解自己的服务。

同时，新增的自定义路由功能，也赋能了现有的 HTTP SERVER，通过引入 lumen 引擎的方式，现在的路由功能也更加强大。

在日志方面，借助 monolog 的能力，我们与 ELK 也进行了结合。简单的配置，就可以让日志入 ELK，更加方便我们进行一些 debug 或是后续的数据挖掘。

为了构建 TARS-PHP 的开放体系，我们引入了 Client & Server filters，它可以让开发者更加方便地在请求前后添加自己的代码。同时我们也开放了 TARS 协议中，向 Context 上下文写入的能力，使得分布式追踪唾手可得。

而为了让 PHP 开发者能够更多地使用 TARS，同时降低自己的迁移成本，TARS-PHP 现在也与 Laravel、ThinkPHP、Yii2、SWOFT 与 Phalcon 进行了整合，后续还将重点接入 Hyperf 与 easyswoole 等业界优秀的框架。通过接入 TARS，相当于赋能了服务打包、云配置与 HTTP/TARS 双协议，又能保持原有的开发框架，一举两得。

在 DevOps 方面，TARS 提供了官方的 Docker 镜像，让开发者能够一键搭建开发环境。而在持续集成上，我们也提供了基于 Jenkins 和 TARS 平台 API 的自动构建方案，让你的代码提交到测试到部署，成为一条龙。

为了让开发者能够更快地使用 TARS，我们也放出了一个使用 TARS 的 HTTP、TCP 与 PB 在内的多种 Server 类型的弹幕服务，存储也涉及到了 Redis 和 MySQL，可以让开发者更容易在自己的项目里把 TARS 跑起来。

TARS-PHP 的开源之路刚刚起步，为了解决文档问题，我们也不断地完善现有的 Gitbook，降低开发者的使用门槛。

在 TARS-PHP 开源一年左右的时间里，我们的项目与衍生项目数超过了 10 个、GitHub repo commit 数量超过 200 次、微信与 QQ 群累计开发者社群人数 800+、Packagelist 下载量 4万+。希望大家也能够加入 TARS-PHP 的建设。