《Linux高性能网络编程十谈》十篇技术博客已经写完几个月了，想着还是写点总结来回顾一下这几年的工作，说来在鹅厂两次经历加起来也快8年，虽然很多时候在做螺丝钉的事情，不过细想自己的高性能架构演进的经历，从参与，优化到最后设计架构，从中还是学到了很多东西。
大家应该都经历过项目从0到1的过程，我想提一个问题：很多时候的架构是随着业务演进还是提前设计呢?
有人可能已经研究过相关的架构书籍，这些书籍大多认为架构是随着业务发展而演变的。然而，也有许多架构师坚持认为架构应该提前设计。在此，我暂时不做结论，而是通过我自己的经历来探讨架构的演进。
PHP作为一门简单便捷的语言，在大厂各个部门应该都有身影，当时我工作用的两种语言：C++和PHP，使用PHP开发功能很快，而且有很多成熟的库，因此组成了经典的nginx
+ php-fpm + memcache架构。
php架构
在当前架构下单台8c8g机器支持1000qps问题不大，所以对于业务当前1wqps都不到，显然多堆几台机器就可以支持了。对于缓存层的设计，在redis还不是发展很好的情况下，memcache是当时缓存组件的主流，而且对于业务和对接PHP简单。但是随着业务的发展，按照当时计算曲线可能一年以内会到5wqps，用nginx
+ php-fpm + memcache架构是不是合理?经过讨论后的目标是服务端高性能，于是开始了高性能的探索之旅。
在当时，为了实现高性能服务端框架，人们尝试了一些方案，其中之一是利用PHP插件功能将Server的功能整合到脚本语言中。这种方法在一定程度上实现了高性能的目标。例如，现在PHP的swoole就是这种方法的一个发展结果。
php-server
不过这里会面临一些需要解决的问题：
基于以上思考和对业务发展的分析，其实我们自己实现一个或者使用现有的C++框架实现一套业务层的Server应该更合理，于是经过考虑采用了公司内的SPP框架，其架构如下：
SPP框架架构
可以看出SPP是多进程架构，其架构类似Nginx，分为Proxy进程和Worker进程，其中：
使用C++的架构后，单机性能直接提升到6kqps，基本已经满足性能上的要求，可以在相同的机器下支持更多的业务，看似已经可以将架构稳定下来了。
使用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高性能网络编程十谈|协程》)。
协程
从架构上还是没有太多变化，多进程+协程的方式，支持着业务发展几年时间，虽然性能上没有指数增长，但是对于高性能探索和沉淀上已经有了更多经验。
业务继续发展，而工程师总是在追求最前沿的理念，云原生作为最近这几年热门的技术点自然不会放过，但是在进入云原生之前，如果你的团队没有DevOps开发理念，这将是一个痛苦的过程，需要对架构设计和框架选择偿还技术债。
以前做架构考虑高性能，随着对于架构的理解，发现高性能只是架构设计的一个小领域，要想做好一个架构，需要更多的敏捷流程和服务治理理念，具体考虑的点总结如下：
DevOps
到这里会发现，简单的高性能Server已经作为架构追求的目标了，于是需要重新调研并设计架构，以顺利实施DevOps的理念。
基于DevOps，结合上面的C++的Server框架，发现多进程已经不能满足架构的需求，原因如下：
业务也发展到百万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的基本框架：
新架构
经历了上述选型和改造后，我们的服务在迁移k8s过程中，按部就班对接就可以了，服务不需要经过太多的改造可以在其平台上运行，对接的各个平台也是可以完整的支持。
看似去追求更新的技术等着下一个风口就可以了?实际这个时候反而挑战更多了，由于在云上的便捷和迁移服务架构的无序扩张，导致业务服务和逻辑层次越来越多，同时一个服务依赖的下游链路越来越长，虽然我们的框架支持链路跟踪，但是链路越长，对服务的可控性和稳定性就越来越差，反而浪费更多的人力支持日常ops。
怎么办?…
是不是要合并业务逻辑，将架构简化?这里面临的问题是业务逻辑复杂情况下往往周期很长，而且从成本角度考虑比较高，收益并不会很大
是不是重新开发的新的架构，将腐朽的保持原样或者抛弃，使用新的架构来适配下一步的发展。
以上是Linux高性能网络编程十谈的详细内容。更多信息请关注PHP中文网其他相关文章！
