图片来自 包图网
接下来我就给你讲一个技术降级的故事。怎么样由牛 x 的技术，换成老掉牙的单体应用。故事内容真实可靠，因为它来自一次真实的咨询。
集中式互联网特点
这个年头，ServiceMesh 都已经在大厂开始铺开，弱一点的也已经是 K8s 驱动的微服务。
这些花架子，全都比 Spring Cloud 这样的一代维服务框架，高了不止一个档次。
这很好，新技术踩在旧技术身上，不停的向前蠕动，最终成为一个有机的整体，也成为技术革新的根本。
注意，我这里使用了蠕动两个字，而不是前进。蠕动意味着丑陋且缓慢，而前进意味着革新和勇往直前。
整个基础设施，就像一条巨大的毛毛虫，升级升级边边角角，最终破茧成为新的物种。它的升级过程是缓慢的，系统关系是复杂多变的。
说是微服务，但它们仍然有以下特点：
- 微指的是服务粒度，而不是模块独立性。缺了大部分模块中的某一个，系统就不能正常运行。
- 脱离了自己公司的环境，就无法运行。
- 几乎无法重建。
你会发现，即使部分业务上云;或者你被某个信仰云搞怕了，想要迁云---都会花费较大的力气。
这么来说吧。即使把你公司里的所有代码，都给偷了出来，你还是不能把项目在你的开发机器上跑起来。
大家默认了这个线上环境是稳定的，各种接口和数据以及 DevOps 工具是完备的。想要数据，直接调其他部门的接口就可以了。
某些公司的痛
但是但是但是，你默认的这个前提，正是某些公司的需求!某些公司的软肋!
因为，除了大部分 toC 的互联网公司，除了能够集中跑在一个地方的类 SAAS 服务，还有很大比重的实施性项目，在闷头发大财。
不要误解，我说的发财，是说老板和销售，而不是程序员。程序员还没这个资格，因为这种公司，上面还有项目经理这一层。
这些系统，需要在某个地方(可能是火星，也可能是客户现场)完成编码，然后被发布到未知的环境之中。
同学们注意了，无论公司包装的再美好，只要是这种模式，那就是外包。比如包装的漂漂亮亮的 thoughtworks，除了几个咨询职位，本质上还是外包。
不是说这种公司不好，只是这种公司不适合走技术路线的程序员。单体应用，是最适合它们的。
有自己产品的也不行。只要是伺候的 B 端大爷，那定制化没跑了。如果产品模型抽象的乱七八糟，那么不好意思，就是外包。
今天，你在黑龙江刚实施了一套系统;明天，就就要带着这套系统去广西，进行为期 3 个月的定制改造。光是部署，就废了九牛二虎之力。
就是在这种场景下，还是有人不加犹豫，选择了微服务。
外表华丽的微服务
微服务有很好的愿景，也有很好的案例。有了微服务的加持，类似奈飞之类的公司，业务得以爆发性的增长。牛 x 的案例也是数不胜数。
微服务要解决的问题，也带有非常大的迷惑性：
迷惑性之一，就可以在 PPT 里或者年度会议上吹牛逼。微字，分布式，高并发，存算分离...，只有这些如此豪横的名词，才能在技术圈拿得出门面。此时，技术界和忽悠界产生了完美的联通。
迷惑性之二，就是在互联网环境里，微服务确实有效。微服务能够降低某些模块的风险，部署灵活，稳定性高。服务松耦合，扩展性高。
看到扩展性三个字，某些决策层就开始脑子发热荷尔蒙上升---这就是我的菜!!
就连不懂技术的老板，也会笑乐了和猴一样。救救他们!别 TM 老盯着优点不放啊。
无数的案例表明，任何华丽的表象下面，都需要大量配套去扫地，微服务也不例外。
微服务运行，其实只需要包含注册中心就行了，其他什么 RPC、熔断之类的，其实在框架内部，并没什么额外部署成本。
但是，这种阉割性的微服务，几乎没什么作用。要想要发挥它的功效，就要建设服务监控、服务追踪、服务治理等;如果模块非常多，还是建设虚拟化...
就这类公司大多数系统的那么点量来说，这些配套系统都不好意思给它们上。
但是好家伙，小伙子们一发力，一个项目拆出来 20 多个微服务。
小伙子们记好了，方向错了，你越努力，效果就越差。你在那加班加点的干，其实是在害公司。
为什么能拆成 20 多个服务?其实，服务粒度是个伪命题。有的人喜欢拆到功能界限;有的人会再加一刀把读写分离也拆了;有的人把服务关系画成一张蜘蛛网;有的人喜欢深入一点的调用---一层套一层。
这些都没什么关系，因为这是水平问题造成的后果，随着服务治理都可以趋向完美。
意识层面的问题才是大事---光顾着吹牛逼体验新技术了，自己技术团队什么水平，心里就没棵 B 树。
就那么几个人的团队，拆成 20 几个服务，还没有配套的 CI 工具，除了折腾人，就没点什么好处。
要命的是，只要你实施一次，这些乱七八糟的东西，就要重新搞一遍吗，你确定每个人都能搞得定么?
上 APM 吧，上监控吧，上 CI 吧。互联网公司在搞的东西，你一样没拉下。关键是，人家每个方向都是团队在搞的东西，现在全交给了你一个人。
改回去吧
错了么?错了!外包公司(原谅我这种叫法，你也可以叫项目类公司)最注重的，就是成本。这么搞，相当于每实施一次，就建立了一个小型公司，把所有的东西重来一遍。
有办法么?有啊。上云就可以了，把这些基础设置交给云去做。但是上云，是另一种形式的中心化，只不过把 SAAS 底层的 IAAS 交给云了。把云机器当作普通机器来用，和上不上云没什么区别。
另外，客户不同意啊。我自己有机器，你给我瞎上云干啥，我根本不相信这些云。
这个时候，你就只能干瞪眼。
还有一种办法，那就是把这些拆好的微服务，再 TM 合并起来。最终打包成一两个 jar 包。发布的时候，拖到服务器上直接启动就好了。
这种合并要注意不要把频率高的小数据量查询和报表类的服务放在一起，否则共用一套资源(连接池、JVM 等)会相互影响。最终建议分成三个就好了：普通服务、报表服务、定时任务。
这种决定是与主流技术相反的，相当于降级。当下了这种决定，小伙伴们嘴都撅的老高---以后出去找工作也不好吹了。但有什么办法呢?
最原始的方法，能够适应任何恶劣的环境，能够忍受任何客户的刁钻。这是由公司的现状决定的。
唯一的问题是，很多人就这么干废了。
结语
每一年，我都会看到很多很多传统行业的人，想要进入到互联网这个圈子。外包和项目类公司，很多也和传统公司无异。具体的区分界限，以前也有较深入的比较。
如果你恰巧在这种行业中，不要迷信互联网公司的技术栈，它们真的水土不服。
互联网的挑战主要是量，而你的挑战是成本。老板想的是快点完工回款，而不是系统的长治久安。这时候，你用的技术花哨，但是没人深入去做，最后就会是一团乱麻。
正是由于对微服务特别了解，我才推荐这些公司不要采用微服务，很好笑是吧。
当然，微服务很好很有魅力，拿来练手是没问题的，但是记得啊，练的差不多在系统上线前，赶紧跑啊。否则锅就是你的了。
作者：小姐姐味道
编辑：陶家龙
出处：转载自公众号小姐姐味道(ID：xjjdog)
