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的崛起，单机时代必然会过去，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。
怎么办?...
是不是要合并业务逻辑，将架构简化?这里面临的问题是业务逻辑复杂情况下往往周期很长，而且从成本角度考虑比较高，收益并不会很大
是不是重新开发的新的架构，将腐朽的保持原样或者抛弃，使用新的架构来适配下一步的发展。
以上的方案其实需要在业务层去权衡，如果本身业务简单，业务逻辑合并周期短，建议采用第一种，如果业务复杂，风险很高，如果开始考虑的架构不合理，就应该采用新的架构。
如果你也有类似的经历，你会发现在这个过程中我们又回到了原点，以前做高性能是为了服务能承载更多性能，简化调用链路，提升开发效率，走到云原生时代，似乎又需要重新走一遍类似的路径，始终没法摆脱服务端的束缚。
4、尝试Serverless
4.1 什么是Serverless
Serverless解释是无服务器计算，开发者实现的服务端逻辑运行在无状态的计算容器中，无需要关系资源，使开发者更聚焦在业务逻辑，而减少对基础架构的关注，业界公认的Serverless计算的准确定义应该为"FaaS+BaaS"，即Function-as-a-Service同Backend-as-a-service的组合。
既然云原生时代我们无法摆脱服务端的束缚去做架构，那在理想情况的Serverless是不是能做到：
Serverless
- 高性能是需要考虑的点，但是服务不再以完全追求高性能为目标
- 降低开发成本和运营成本
- 支持服务的横向扩展和纵向扩展
- 对于开发者最好是省去CI/CD流程，但是平台将这些流程作为发布的前置条件
- 云上的资源拿来就可以直接用，只需要评估容量即可
- 缩放灵活，可以减少资源的使用
- 考虑服务的安全性
- ...
4.2 基于微内核的云函数
从最开始的PHP到C++的框架迭代，一直在围绕高性能，服务治理等在优化，但是要结合Serverless，简化架构层级，于是萌生实现一套基于微内核的云函数架构。
其实参考AWS Lambda的技术路径也是如此，他们正在尝试轻量化容器和microVM去解决慢启动问题，而我们使用微内核解决业务边界和安全问题，因为场景的是可以枚举的，不需要做到足够非常通用化，于是形成如下架构：
新架构
这里微内核主要做的事情有两个：
一种是实现业务层代码解析，比如对于JavaScript，我们可以通过自定义的解析引擎将代码加载到微内核中，调用基础库和各种抽象API层，相当于实现了一个简单版本的NodeJS，但是整个框架的安全和功能都是在可控的范围内;
一种是自定义其他语言，比如定义支持golang，那么MicroVM负责将golang层的代码和框架代码打包在一起，然后编译构建为镜像，不过我们正在考虑支持更多的语言，这里尝试使用Webassembly，这样能简化镜像构建成本，直接MicroVM动态加载wasm文件即可;
使用基于微内核的云函数的优点是，这里对于开发者简单，真正只需要做业务逻辑，不需要考虑底层的高性能(现在已经支撑百万级QPS)，更不需要关注DevOps某些流程，提升了开发效率，当然也有缺点，就是由于MicroVM偏向业务层抽象基础功能，所以通用性不强，但是对于现有或者后续的业务形态的发展已经足够了。
5、总结
写到这里，再来聊聊这个问题：提前设计还是业务演进?大家应该都有自己的答案了。上述也是我从开发者小白追求如何写好一个高性能Server，到追求新的架构技术，到最后思考高性能，新技术到底是为什么服务的一段总结。本文属于《Linux高性能网络编程十谈》附加篇，没有具体谈高性能的技术细节，但是我觉得这句话比技术细节可能更重要："架构需要大简至道"。
