《linux高性能网络编程十谈》系列博客已完成数月，回顾这几年的工作经历，我在鹅厂的两次工作加起来将近8年。虽然大部分时间都在做基础性工作，但回顾高性能架构的演进过程，从参与到优化，再到最终设计架构，我从中学到了很多。
1、提前设计还是业务演进？在项目从0到1的过程中，大家都经历过架构的选择问题：是随着业务演进还是提前设计？虽然很多架构书籍支持随着业务演进的观点，但也有许多架构师认为应提前设计架构。通过我个人的架构演进经历，我们来探讨这个问题。
2、从PHP到C++2.1 简单的PHP架构PHP作为一门简单易用的语言，在大厂各个部门都有应用。我的工作涉及两种语言：C++和PHP。使用PHP开发功能非常快捷，且有许多成熟的库，因此形成了经典的nginx + php-fpm + memcache架构。
php架构
在这种架构下，单台8c8g的机器可以轻松支持1000qps，而当时业务的需求不到1wqps，显然多加几台机器就能满足需求。对于缓存层的设计，在Redis尚未普及时，Memcache是主流选择，且与PHP对接简单。但随着业务发展，预计一年内将达到5wqps，继续使用nginx + php-fpm + memcache架构是否合理？经过讨论，我们决定追求高性能服务端，于是开始了高性能探索之旅。
2.2 多进程的框架在PHP中实现高性能服务端框架有一些方案，例如通过PHP插件将Server功能嫁接到脚本语言上，从而实现高性能。比如现在的PHP的swoole就是从当时发展起来的。
php-server
然而，这也带来了几个需要解决的问题：
- 熟悉PHP扩展的使用场景，避免踩坑
- PHP本身的内存泄漏问题
- 出现问题时的排查成本高，可能需要研究PHP源码
- PHP的生态系统能否适应Docker的兴起和单机时代的终结
基于这些考虑和业务发展的分析，我们决定自己实现一个或使用现有的C++框架来构建业务层的Server。最终选择了公司内部的SPP框架，其架构如下：
SPP框架架构
SPP框架采用多进程架构，类似于Nginx，分为Proxy进程和Worker进程：
- Proxy进程使用
handle_init进行初始化，使用handle_route将请求转发到指定的Worker进程，使用handle_input处理请求的入包 - Worker进程使用
handle_init进行初始化，使用handle_process处理包和业务逻辑并返回结果
使用C++架构后，单机性能直接提升到6kqps，基本满足性能需求，可以在相同的机器上支持更多业务，看似可以稳定架构了。
2.3 引入协程虽然C++在性能上已满足需求，但在开发效率上存在问题。例如访问Redis，为了保持高性能，代码逻辑采用异步回调，如下所示：
...int ret = redis->GetString(k, getValueCallback)...
其中getValueCallback是回调函数，处理多个IO操作时，回调会变得非常复杂，即使封装成类似同步方式，处理起来也很麻烦。当时还没有引入std::future和std::async。另一方面，考虑到后续QPS可能达到10~20万，协程在多IO服务处理上的性能更有优势，于是开始了协程改造，将IO操作替换为协程调用，对于业务开发，代码变成了这样：
...int ret = redis->GetString(k, value)...
其中value是可以直接使用的返回值，一旦代码中有IO操作，底层就会将IO替换为协程的API，这样阻塞的IO操作就变成了同步化原语，代码结构和开发效率都有了显著提升（具体的协程实现可以参考系列文章中的《Linux高性能网络编程十谈|协程》）。
协程
从架构上看，虽然没有太多变化，但多进程+协程的方式支持了业务发展几年时间。虽然性能没有指数增长，但在高性能探索和经验积累上有了更多收获。
3、云原生随着业务的继续发展，工程师总是在追求最前沿的理念。云原生作为近几年的热门技术点自然不会放过，但在进入云原生之前，如果团队没有DevOps开发理念，这将是一个痛苦的过程，需要对架构设计和框架选择偿还技术债。
3.1 实施DevOps理念以前做架构时主要考虑高性能，随着对架构的理解加深，发现高性能只是架构设计的一个小领域。要想做好一个架构，需要更多的敏捷流程和服务治理理念，具体考虑的点总结如下：
- 持续集成：开发人员一天多次将代码集成到共享存储库中，并对每个孤立更改立即进行测试，以检测并防止集成问题
- 持续交付：确保可以在CI存储库中测试的每个版本的代码随时发布
- 持续部署：包括灰度部署、蓝绿发布等，目的是快速迭代，通过相对完整的集成测试后进行灰度验证
- 服务发现：将服务作为微服务化，简化服务之间的调用
- RPC的框架：追求高性能的Server框架，也需要考虑限流、熔断等基础组件的支持
- 监控系统：集成Promethues、OpenTracing等功能，能在敏捷开发流程中快速发现线上问题
- 容器化：为了环境统一，同时提前考虑云原生场景，容器化是开发过程中必不可少的
DevOps
到这里会发现，简单的高性能Server已经不再是架构追求的唯一目标，于是需要重新调研并设计架构，以顺利实施DevOps理念。
3.2 多线程基于DevOps，结合之前的C++ Server框架，发现多进程已经不能满足架构需求，原因如下：
- 多进程与Docker容器的单进程理念不相符
- 工作进程负载不均，如何更好地利用多核
- 与监控系统有效对接
- 业务配置重复加载，需要重新适配配置中心
- 使用多进程做有状态的服务不合理
业务也发展到百万QPS，为了更好的服务治理和服务调用成本，不得不考虑其他架构：
（1）调研gRPC
gRPC
gRPC是多线程RPC Server，具有成熟的生态，支持多语言等，对于从0到1开发的业务是一个不错的选择。但对于业务迁移却面临挑战，例如开发自己的中间件以适配服务发现、配置中心等，改造协议以实现自定义编解码，如何结合协程等。因此，gRPC对于部分业务适用，但仍需更好的结合公司内组件的RPC Server。
（2）使用tRPC
公司内部正在开发tRPC，经过调研发现基本满足需求，于是我们在tRPC的C++版本刚刚发展初期就尝试适配我们的系统。经过一系列改造，高性能的RPC框架在业务系统中迁移和使用了，其中tRPC的架构：
https://www.php.cn/link/6b42c916702e0bd86f86a3bb84fc7aa2
基于上述考虑和业务的发展，我们开始尝试以高性能为基础，将RPC Server框架统一，以适配后续RPC多样化场景，于是实现了一套适配我们业务系统的RPC Server基本框架：
新架构
3.3、走向k8s经历上述选型和改造后，我们的服务在迁移k8s过程中，按部就班对接即可，服务不需要经过太多的改造就可以在其平台上运行，对接的各个平台也能够完整支持。看似去追求更新的技术等着下一个风口就可以了？实际这个时候反而挑战更多了，由于在云上的便捷和迁移服务架构的无序扩张，导致业务服务和逻辑层次越来越多，同时一个服务依赖的下游链路越来越长。虽然我们的框架支持链路跟踪，但链路越长，对服务的可控性和稳定性就越差，反而浪费更多的人力支持日常ops。
怎么办？
- 是不是要合并业务逻辑，将架构简化？这里面临的问题是业务逻辑复杂情况下往往周期很长，而且从成本角度考虑比较高，收益并不会很大
- 是不是重新开发新的架构，将腐朽的保持原样或者抛弃，使用新的架构来适配下一步的发展
