老板觉得冷,服务如何缩容?

语言: CN / TW / HK

原创:小姐姐味道(微信公众号ID:xjjdog),欢迎分享,转载请保留出处。

大环境稳中向好,公司却不行了。为什么?肯定是自己的问题,这怪不得别人。在任老板紧裹大袄的今天,我们也没必要穿着秋裤耍帅,保暖措施是一定要跟上的。

这些保暖方案,除了要降本增效把可怜的劳动者变成灵活劳动者,原则上我们还可以对服务运行的寄主,这就是躺在机房里的那些硬件采取一些措施。

假如CPU一直没跑满,我们就要想着让它一直极限运行;如果磁盘富余,那可以使用MinIO再在上面搭建一套文件系统;JVM的内存分配也要省着点,方便以后进行混合部署...

如果老板觉得很冷,作为员工xjjdog绝对不可以眼睁睁看他冻死。这样的措施很多,我们要出方案,找抓手,真正的落实下去。

搭建监控系统

想要知道每个部件的温度,看这些硬件有没有偷懒,有没有瞒报误报,我们需要搭建一套完整的监控系统来对这些硬件进行监控,它们绝对逃不出我们的五指山。

传统的资源是CPU、内存、网络、I/O,当然我们也可以扩大一点,把更上层的软件劳动者也囊括进来,包括数据库、MQ、SLB等诸多组件。

这套系统可以采用占用资源较少的组件,比如Telegraf进行指标指标,Prometheus进行指标存储,只保存1天的时间。至于展示,一个Grafana就可以满足需求,我们可以直接使用潜入的sqlite来保存监控面板。至于报警,不要再发邮件、发短信了,花钱。我们人工去盯就可以了。

抓数据也要平衡花费,不能在保暖的步伐中首先冻死了自己。抓取的间隔可以调高到30s或者1min;参数也要调整好,像CPU利用率,我们只抓总的就好了,没必要抓取单核的。

觉得冷一般是一个整体觉得冷,抓单核CPU不符合平均主义的精神。有了监控系统,我们就相当于有了抓手,这措施就有一定的针对性,在缩容的进程中就多了一些掌控度。

去容器化

容器很好,但有成本。无论Namespace隔离的再好,总有运行成本。再加上k8s的维护人员,镜像的存储仓库,所谓的云原生等一系列Proxy,在公司势必会造成大的浪费。

先别再研究什么ServiceMesh了,我们先把容器去掉。

对于Java来说,WAR包、JAR包,都是比较好的运行方式。对于其他语言来说,二进制也很好,不用再用Docker包上一层。

使用Jenkins来替代Rancher或者采购的k8s系统,可以省下一部分授权费用,而且服务运行的更清爽。顺便,也可以把k8s团队整个给优化掉,因为他们在缩容的环境中根本不是那么重要,反而是公司的累赘。

xjjdog在十几年前,一个Tomcat,一个ssh远程命令行,服务就能运行的很好。纵观这些年,容器化发展纵然迅速,但公司的业务却每况愈下。这证明了先进的技术并不能助力业务的发展。

够用就好。有时候追求潮流反而尾大不掉,企业有缩容的需求,去容器化就是必须要实行的。

去微服务化

接下来,我们要把公司的业务进行单体化。把原来拆的七零八落的微服务模块给合并起来。

公司下行,业务也变的稳定,微服务的魔力已经一去不复返,是时候把它们放在一个Idea项目中来运行了。

ERP、CRM、Shop、Front?没有什么不是一个独立的git项目不能管理的。相对于RPC这些耗时的调用,直接方法内调用会节省下大量的硬件。流量的节省,机器的节省,这都是微服务不能比拟的。

微服务到单体的改造,我们要从下游开始,逐步向上游靠拢。原来是RPC调用,现在我们只需要把它封装成一个jar包,然后让业务进行集成就好了。

这个过程可能是痛苦的,但一旦完成了改造,什么注册中心、日志手收集、熔断、分布式锁等组件,都可以说bye了。

公司没业务,与其让开发人员在那里闲着没事做,不如加加班,把微服务改造成单体。这部分省下来的钱,换量新车,再不济出去旅个游,不爽么?

其实,把微服务做成单体,还可以降低迁移成本。这个我们接下来说。

去云化

千万不要买什么云上的产品,比如RDS或者MQ或者什么Log服务,这些开源组件都是现成的,云服务商简单的包装了一层就拿来卖钱。它们的棉袄倒是厚了,作为企业我们都没有裤头穿。

这不能忍。

要用云服务,也就简单的买裸机就好。就买那种大容量的,大cpu大内存。如果一台机器的利用率没有涨上去,我们就可以再在上面添加一些服务,就是这么简单。

随着业务的访问量越来越少,这些大容量的机器可以越来越少。这是后话,我们首先要干掉的就是云产品。

像MySQL,你搞那么多实例干什么?通过开不同的账号,我们可以让所有的系统使用同一个MySQL实例。这样备份都好做,只需要挂上个从机,或者定期拉一下Binlog就好了。

像MQ、缓存,各种系统,没有什么不是不能共用的。你买了云厂商十几二十个实例,结果发现最后搭建一个就满足需求了,何苦花这个钱、费这个劲,来满足一个半死不活的业务呢?

完成混合部署

很多年前,混合部署还是一种潮流。容器出来之后,混合部署就逐渐落于下成。主要是混合部署,服务之间会相互影响,也无法进行资源隔离。

但今日不同往昔了兄弟们,公司几百个服务的运行情况,已经是可以预见的处于那种水平,再也不可能来个10倍流量,百倍秒杀这样的场景了。

把这些可怜的小家伙们部署在一块,是必然的选择。况且,经过我们的单体化改造,微服务已经没有了,这些服务数量上必然是可控的。为了让实施速度快一点,我们也推荐买大容量的CPU、内存等,这样也方面我们日后调整。

资源调整

当这一切完成之后,你会发现,缩容竟然也是这么的美妙。人变少了,团队好管理;机器变少了,掌控力就变强。有些公司,在进行这些非常Nice的改造之后,会发现一台16C32G的机器,就能够Hold住公司的所有业务了。

但16C32G也是钱啊,而且每个月都付,我们的缩容还没到极致。这时候监控系统的作用必须要体现。

如果某台机器的CPU一直处于低水位运行,说明你的服务调度是不合格的,你需要调整每台机器上部署的服务的情况。这通常是拷贝一下程序,修改一下Ng的配置文件就能完成的事。

JVM的内存监控也要走起来,除了堆,像什么MetaSpace、堆外内存也要控制起来,够用就好。如果你担心一些突发情况把进程搞Down了,那么可以使用systemctl做个自动重启。相信对于技术高超的你来说,这都不是问题。

其他

当然,上面的缩容都是一些指导思想。我们的目标就是降低机器使用的数量。像性能优化、日志缩减这些就不多谈了,因为它们对技术要求比较高。

另外,任何花钱的地方,都可以让它不花钱。就拿HTTPS来说啊,证书要花钱,没必要让用户的数据走什么安全通道。况且现在移动端访问谁也看不出到底是不是HTTPS,证书这种东西能去掉就去掉吧,没人在乎。

高可用建设的这一块,从DNS到组件的主从,甚至某些服务的负载均衡。只要能处理业务,也没必要为了这些几乎永远看不到的风险点花这些冤枉钱。

退一万步讲,假如缩容之后,我们的公司还是很冷,活不了几天。我们还可以把这些单体应用开源出去,做点教程卖钱。

单体应用,用鼠标点吧点吧就能跑,学生、老板和培训机构们最喜欢了。

作者简介: 小姐姐味道 (xjjdog),一个不允许程序员走弯路的公众号。聚焦基础架构和Linux。十年架构,日百亿流量,与你探讨高并发世界,给你不一样的味道。我的个人微信xjjdog0,欢迎添加好友,进一步交流。

推荐阅读:

1. 玩转Linux

2. 什么味道专辑

3. 蓝牙如梦

4. 杀机!

5.  失联的架构师,只留下一段脚本

6.  架构师写的BUG,非比寻常

7.  有些程序员,本质是一群羊!