《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插件功能将Server的功能整合到脚本语言中。这种方法在一定程度上实现了高性能的目标。例如，现在PHP的swoole就是这种方法的一个发展结果。
php-server
不过这里会面临一些需要解决的问题：
- 熟悉PHP扩展的使用场景，防止踩坑
- PHP本身使用上的内存泄漏问题
- 出现问题时的排查成本，比如一旦出现问题，我们有时候需要去了解PHP源码，但是面对几十万行代码，这个成本是相当高
- PHP使用上简单，这个实际相对的，随着Docker的崛起，单机时代必然会过去，PHP的生态是不是能支持
- …
基于以上思考和对业务发展的分析，其实我们自己实现一个或者使用现有的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~20w量级，协程在多io的服务处理的性能上也会更有优势，于是开始了协程方式改造，将io的地方全部替换为协程调用，对于业务开发来说，代码上就变成了这样：
... int ret = redis->GetString(k, value) ...
其中value就是可以直接用的返回值，一旦代码中有io的地方，底层就会将io替换为协程的API，这样阻塞的io操作就全部变成同步化原语，代码结构和开发效率都提升不少(具体的协程实现可以参考系列文章的《Linux高性能网络编程十谈|协程》)。
协程
从架构上还是没有太多变化，多进程+协程的方式，支持着业务发展几年时间，虽然性能上没有指数增长，但是对于高性能探索和沉淀上已经有了更多经验。
3、云原生
业务继续发展，而工程师总是在追求最前沿的理念，云原生作为最近这几年热门的技术点自然不会放过，但是在进入云原生之前，如果你的团队没有DevOps开发理念，这将是一个痛苦的过程，需要对架构设计和框架选择偿还技术债。
3.1 实施DevOps理念
以前做架构考虑高性能，随着对于架构的理解，发现高性能只是架构设计的一个小领域，要想做好一个架构，需要更多的敏捷流程和服务治理理念，具体考虑的点总结如下：
- 持续集成：开发人员一天多次将代码集成到共享存储库中，并且对代码的每个孤立更改都将立即进行测试，以检测并防止集成问题
- 连续交付：连续交付(CD)确保可以随时发布在CI存储库中测试的每个版本的代码
- 连续部署：这里包括灰度部署，蓝绿发布等，目的是快速迭代，经过相对完整的集成测试，就可以灰度验证
- 服务发现：将服务作为微服务化，简化服务之间的调用
- RPC的框架：追求高性能的Server框架，也需要考虑限流，熔断等基础组件的支持
- 监控系统：集成Promethues，OpenTracing等功能，能在敏捷开发流程中快速发现线上的问题
- 容器化：为了环境统一，同时提前考虑云原生场景，容器化是开发过程中必不可少的
- …
DevOps
到这里会发现，简单的高性能Server已经作为架构追求的目标了，于是需要重新调研并设计架构，以顺利实施DevOps的理念。
3.2 多线程
基于DevOps，结合上面的C++的Server框架，发现多进程已经不能满足架构的需求，原因如下：
- 多进程与Docker容器的单进程理念不相符
- 工作进程负载不均，如何更利用多核
- 与监控系统有效的对接
- 业务配置重复加载，需要重新适配配置中心
- 用多进程做有状态的服务不是很合理
- …
业务也发展到百万QPS，为了更好的服务治理和服务调用成本，不得不考虑另外的架构：
(1)调研gRPC
gRPC
gRPC是多线程RPC
Server，有成熟的生态，各种中间件，支持多语言等，对于从0到1开发的业务是一个不错的选择，但是对于业务迁移却面临挑战，比如开发自己的中间件适配服务发现，配置中心等，改造协议按照自定义编解码，如何结合协程等，因此对于部分业务满足，但是还需要更好的结合公司内组件的RPC
Server。
(2)使用tRPC
刚好公司内正在开发tRPC，经过调研发现基本满足需求，于是在tRPC的C++版本刚刚发展初期就尝试适配我们的系统，经过一系列的改造，高性能的RPC框架在业务系统中迁移和使用了，其中tRPC的架构：
https://trpc.group/zh/docs/what-is-trpc/archtecture_design/
基于上述的考虑和业务的发展，于是开始尝试以高性能为基础，将RPC Server框架统一，以适配后续RPC多样化场景，于是实现一套适配我们的业务系统的RPC
Server的基本框架：
新架构
3.3、走向k8s
经历了上述选型和改造后，我们的服务在迁移k8s过程中，按部就班对接就可以了，服务不需要经过太多的改造可以在其平台上运行，对接的各个平台也是可以完整的支持。
看似去追求更新的技术等着下一个风口就可以了?实际这个时候反而挑战更多了，由于在云上的便捷和迁移服务架构的无序扩张，导致业务服务和逻辑层次越来越多，同时一个服务依赖的下游链路越来越长，虽然我们的框架支持链路跟踪，但是链路越长，对服务的可控性和稳定性就越来越差，反而浪费更多的人力支持日常ops。
怎么办?…
是不是要合并业务逻辑，将架构简化?这里面临的问题是业务逻辑复杂情况下往往周期很长，而且从成本角度考虑比较高，收益并不会很大
是不是重新开发的新的架构，将腐朽的保持原样或者抛弃，使用新的架构来适配下一步的发展。
