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