当谷歌员工来到新公司的那一天，发现原来公司什么都没有

云栖大会是阿里每年一次的秀肌肉，2020年的云栖大会采用了云上直播，昨天一天把云栖大会的内容整体上算是看了一遍，当然更多是挑着看的，不然太多了。总体的感觉阿里还是国内技术最过硬的公司之一（主要是考虑到华为）。而且在进入云原生的软件研发时代，坐拥阿里云一系列云效解决方案，还是可以很好的为自己不同的商业生态和场景赋能的。

同时看到了各种高P的分享和CTO的分享，还是会有醍醐灌顶的感觉，很多时候我们都会懂得一些道理，但是还是处于怀疑的阶段，但是高P给你了一个相似的输入之后，你对这个道理就不会在怀疑了，谁让人家是高P呢？

云栖的其他感悟有时间再写一篇，今天这篇是在看的过程中听到了这样一句话：

当谷歌员工来到新公司的那一天，发现原来公司什么都没有。br

确实一些头部公司的程序员在离开了大公司之后来到其他公司会产生很多不适应性，主要是新公司的基建太差了，什么都得自己搞。

自己搞也挺好，可以对业界的一些前沿概念在公司落地一波，如果有比较好的产出，能力提升还是很快的，自己职业生涯也会进入一个新的阶段。

我的一个同学在（当然也在独角兽公司）所负责的业务方向上，落地了一套Service Mesh，Serverless，Devops解决方案，后来拿到了阿里的8。和他聊了下，虽然方案本身并不是特别复杂，也不是业界的最优解，但是强就强在了这些牛逼的概念他可以落地下来，也符合了行癫的那句：

阿里人要善于给自己画饼，并且把饼吃掉。br

我想到了之前看到过的一个例子，如果环境不允许，那就自己创造问题并解决问题，以获得提升。

很多公司都通过HAProxy做流量代理，但是很多时候下游服务实例总会上下线，如果服务数量少还可以手动修改配置文件重启HaProxy。

但是如果服务数量变多，并对整体故障转移的可用性有比较高要求，这么做就不是那么ok了。那有没有好的解决方案可以兼顾下游服务上下线，还可以实现热更新，减少不可用时间呢？

Airbnb有个Synapse方案，思路是通过自动生成配置文件+管理HAProxy进程。但是每次重启进程还是对稳定性有影响，有没有方案可以实现不需要重启进程立马生效呢？可以自己实现一个类HAproxy的解决方案吗。

这个方案优点类似于Mesh的解决方案，所以我们就叫他sidecar吧。

sidecar作为一个独立的客户端对整个微服务集群提供透明代理，有良好的性能和可用性。sidecar部署到每台生产环境的vm或容器中，可以为微服务和redis，mysql，mq等做网络代理。

sidecar实现有如下要求：

1. 轻量级，高性能：sidecar采用golang实现，具有高性能，资源占用少特点，可以作为独立进程和应用程序部署到一起（所以知道go的特点和使用场景了吧）。

2. 支持热更新配置，无需重启：运行时可以动态从远端获取代理规则和代理策略，并且实现变更，实时生效。这样不会导致服务的不可用，大大降低了运维成本，为后续的大规模云环境适配提供了基础。

3. 故障感知与故障转移：sidecar定期对服务状态进行健康检查，支持tcp，atcp，mysq，redis等检查，可以实时剔除故障节点并转移对应流量，当节点恢复后再次将实例加入。

4. 提供Rest API进行管理：一个好的管理功能应该是扩展性和兼容性都比较高的，etcd和es都有比较好的管理rest api，通过Rest API可以获取运行时的信息，如config和status，可以动态调整日志级别，性能分析pprof等。

5. 运行时观测性：作为请求转发中心可以实时记录链接情况和请求情况，将请求频次，耗时，失败率等指标进行上报，通过prometheus进行可视化展示，数据采集指标有利于了解服务和网格状态，为做出决策提供依据。

状态指标还有:

• 命令级别打点: 统计每种命令的执行时间P99、请求参数和返回结果长度等

• 集群级 scan: 通过普通的 scan 命令可以对整个集群进行数据扫描

• 透明(解)压缩: 对大 key 进行透明压缩，节省缓存空间和机器带宽占用

• 热 key 实时收集: 实现了 hotkey 命令，使得业务可以快速定位热点 key

sidecar负责订阅代理配置和服务实例变更，依照配置规则对用户端流量进行转发。

sash是数据屏幕，负责管理服务器，提供代理配置，数据规则的实时推送，以及一些基础的运维工具，如：部署升级等。

早期sidecar只做四层代理，也就是简单的流量拷贝，但是缺少对于应用层指标的处理，无法为应用层的业务提供更多的帮助，所以需要对协议进行进一步的丰富去支持更多业务场景的诉求。

以redis为例，如果公司不同的redis版本，可以对redis协议进行转发，比如讲redis2的请求翻译之后转发给redis3进行处理。

所以基于sidecar完善了对于redis协议的翻译和转发，也支持了七层应用层的协议代理，更好服务于业务。

改造挑战主要有以下几点:

1. 如何保证与 corvus 命令兼容，并性能相差不大?

2. 支持了七层，会不会占用较多的资源影响到业务应用?

3. 四层到七层，复杂度大幅度提升，如何保持项目质量与稳定?

4. 生产环境有上千个 corvus集群，如何悄无声息地下线掉并且不影响业务?

完成了 Redis Cluster 代理的开发，但还有很多东西可以优化，可以适配支持更多的协议如 MySQL、MQ等。

你看小公司还是有很多值得落地的东西的，相比于大公司具有太多现成优秀的解决方案，小公司发挥的空间，提升能力的点还是很多的。