老板觉得冷，服务如何缩容？

原创：小姐姐味道（微信公众号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。十年架构，日百亿流量，与你探讨高并发世界，给你不一样的味道。