世界上只需要 Nginx 和 HAProxy 足矣

Posted 2021-05-01 鲭物语

nginx 有多好？对大多数人来说，只需要编辑下配置文件就可以了，只需要保证逻辑正确，客户端的请求能被正确的 proxy 到 合适的 upstream 就可以了。

Nignx 哪里不好用？如果有的话，估计就是配置语法太多记不住，有些坑自己不亲自趟是看不出深浅的。尽管如此，也挡不住 nginx 势如破竹的普及趋势。

就当我们利用 nginx 做各种反向代理之时，努力学习通过 lua 对 Nginx / Openresty 进行扩展的时候，咣，又出来个 service mesh 的概念，以及各种如雨后春笋般出现的 Envoy 、istio 、Cilium 和 Conduit ？

不可否认，微服务确实是趋势，K8s 也基本成了构建 PaaS 以及集群调度平台的标准实现方式，随着这些基础设施以及 cloud native 的渐入人心， service mesh 的出现也没法说完全不能理解。

好处就不说了，说说不好的地方，微服务不好调试，出了问题定位难，管理成本高，K8s 部署复杂，未知的坑比较多。Istio 就能解决这个问题？

Service mesh 的一个功能就是实现系统的可观测性，对系统整体的运行状态有所把控，其涵盖范围要大于传统的监控和报警；而且，对系统的可观测性，要求对系统内部的实现非常了解。那我的问题就来了，这个配置文件谁来写？Dev？Ops？还是 DevOps ？

商品、服务或是软件，制作者都应该让用户变成“傻瓜”，让用户用起来简单。

开发工具和框架已经正在逐渐把软件工程师变成“码农”，很多应用程序就是 CRUD 而已，基本设计的时候就能把代码生成了； IaaS 以及 PaaS 等各种 XaaS，也大大简化了运维工作以及难度，从这两点来说，开发和运维都在变得越来越傻瓜。同一件事，在其他方面都一样的情况下，一定是最简单的最后胜出。

其实我也不清楚 service mesh 到底应该做成什么样才好，但是最近对一些事挺有感触的。比如不要干一件事提供 n 种方案，让用户选择也是负担，再比如 gofmt 和 go fmt 不应该放一块更好些么？

Docker 之所以这么火，还不是把 10 条 lxc 的命令合成了一条 docker run ？简单的话入手就快，当然普及会更快。然而 K8s 并不是走的这条线，在我看来，g 家的号召力，以及其强大且全面的功能，是很多人选择的关键因素，当然其核心是社区的强大之处，这也和 Docker 公司的哲学有些相悖，所以 Docker 公司最近两年一直被唱衰。

Docker swarm 曾经是个好东西，但是我想我也不会再去研究它，至少现在没这个打算。因为我知道，跟 K8s 应该不会太差，工作好找，收入也不会低，算是软件工程师的必备技能之一，在某些公司或者职位来说，可能是关键的决定性技能。

我们真的都需要 PaaS 么？CaaS 或 Serverless ，都有其优点，简单的代价就是可控性差，灵活度低，在别人的框架里写代码。以前接触过代码生成工具，就是从设计流程，自动生成源代码，可以理解为 UML 图生成类，但是比这负责，能生成业务逻辑的代码，也许将来有一天，我们本地都不需要 IDE，直接在服务提供商的页面拖拖拽拽就能组装自己的应用程序了。

这时不得不说到 full managed service，简单来说，就是所有基础设施都由平台方提供，自己只写业务代码，比如 PaaS 和 Serverless 都是这样的，IaaS 实际上除了虚拟机实例，也提供了类似的服务。自己不需要管理数据库、缓存和消息队列，只需要出 money 就可以了。

穷惯了就不敢进行高质量的消费，编写软件也应该适时偷懒，能用钱办到的事情，尽量别自己去做，别人更专业，自己更省心。

懒人真希望世界上只有 HAProxy 。

当然，一涉及到企业级，以上都全作废。