图片来自宝途网接下来给大家讲一个技术降级的故事。把牛X的技术换成一个老套的单体应用怎么样。故事的内容是真实的，因为它来自真实的咨询。中心化的互联网特性这些年ServiceMesh已经开始在大厂铺开，比较弱的已经是K8s驱动的微服务了。这一切的摆设，比SpringCloud这样的一维服务框架高了不止一个层次。这是非常好的。新技术踩在旧技术之上，不断前行，最终成为一个有机的整体，这也成为技术创新的基础。请注意，我在这里使用了爬行一词，而不是前进。蠕变意味着丑陋和缓慢，而前进意味着创新和前进。整个基础设施，就像一条巨大的毛毛虫，不断升级自己的棱角，最终破茧而出，成为新的物种。其升级过程缓慢，系统关系复杂多变。说是微服务，但还是有以下特点：微指的是服务粒度，不是模块独立性。如果缺少其中一个模块，系统将无法正常运行。如果脱离了自己公司的环境，就无法运作。几乎不可能重建。你会发现，即使有些业务上云；或者，如果你害怕某个信念云，想要迁移到云中——这将需要付出很大的努力。让我们这样说吧。即使你公司的所有代码都被盗了，你仍然无法在你的开发机器上运行项目。默认线上环境稳定，各种接口、数据、DevOps工具齐全。如果要数据，可以直接调用其他部门的接口。有些公司的痛但是但是但是，你默认的前提恰恰是有些公司的需求！一些公司的软肋！因为，除了大部分toC互联网公司，除了类似SAAS的服务可以在一处跑起来，还有很大比例的实施项目，枯燥而丰富。别误会，当我说致富时，我指的是老板和推销员，而不是程序员。程序员还不算合格，因为这种公司有一层项目经理。这些系统需要在某个地方（可能是火星，或者客户站点）进行编码，然后发布到一个未知的环境中。同学们注意了，不管公司的包装再漂亮，只要是这种模式，就是外包。比如包装精美的thoughtworks，除了几个咨询岗位外，基本上都是外包的。并不是说这种公司不好，只是这种公司不适合走技术路线的程序员。单体应用程序最适合他们。甚至那些拥有自己产品的人也不行。只要服务的是B端大叔，那定制就没了。如果产品模型抽象、凌乱，那不好意思，是外包了。今天，你们刚刚在黑龙江实施了一个系统；明天，您将带着这套系统去广西进行为期三个月的定制化改造。光是部署就浪费了很多精力。即使在这种场景下，也有人毫不犹豫地选择了微服务。外观华丽的微服务微服务有一个好的愿景和一个好的案例。在微服务的加持下，像Netflix这样的公司业务出现了爆发式增长。牛x的案例也数不胜数。微服务要解决的问题也很扑朔迷离：其中一个扑朔迷离的可以是在PPT或者年会上吹牛。微词、分布式、高并发、存储计算分离……也只有这些大胆的名词，才能在技术圈露个脸。这时候，科技世界和闪烁世界有了完美的连接。第二个困惑是在互联网环境下，微服务确实有效。微服务可以降低某些模块的风险，部署灵活，稳定性高。服务是松耦合和高度可扩展的。看到可扩展性这三个字，有些决策者会开始觉得火辣辣的，荷尔蒙会飙升---这是我的菜！！连不懂技术的老板都会笑得跟猴子似的。拯救他们！不要他妈的只盯着优点看。无数案例表明，任何华丽的外表下，都需要大量的配套设施来扫地，微服务也不例外。其实微服务运行只需要包含注册中心即可。其他的RPC、断路器等其实都在框架内部，没有额外的部署成本。但是，这种阉割微服务几乎没有效果。要想发挥它的作用，就需要构建服务监控、服务跟踪、服务治理等；模块多的话，就建虚拟化吧。。。这种公司的大部分系统，这些配套系统我都不好意思给。不过好样的，小伙子们一努力，一个项目就拆掉了20多个微服务。记住伙计们，错误的方向，你越努力，你的效果就越差。你在那里加班，其实是在害公司。为什么可以拆分成20多个服务？事实上，服务粒度是一个伪命题。有些人喜欢拆到功能边界；有些人会加刀拆解读写分离；有些人把服务关系画成蜘蛛网；层。没关系，因为这是层次问题的后果，可以通过服务治理来完善。意识层面的问题是大问题——如果我忙着吹嘘尝试新技术，我心里就没有B树。一个几个人的团队，拆分成20多个服务，没有配套的CI工具。除了折腾人，没有任何好处。最糟糕的是，只要你实施一次，这些乱七八糟的事情还需要再做一遍吗？你确定每个人都能应付吗？转到APM，转到监控，转到CI。互联网公司正在做的事情你没有放过。重点是每个方向都是团队在做的事情，现在都交给你一个人了。改回来。这是错的吗？错误的！外包公司（恕我这样称呼，你也可以叫它项目公司）最看重成本。这样做相当于每次实施都成立一个小公司，一切都重做。有办法吗？是的。就上云端吧，把这些基本的设置都交给云端。但是，上云是另一种形式的去中心化，只是把SAAS的底层IAAS转移到云端。把云机当作普通机使用，和上不了云没什么区别。另外，客户不同意。我有我自己的机器，你为什么要盲目地给我用云，我根本不相信这些云。这个时候，你只能发呆。还有一种方式，就是把这些拆解出来的微服务组合起来，然后TM。最后打包成一两个jar包。发布的时候直接拖到服务器上，直接启动即可。这种合并注意不要把高频小数据量的查询和报表服务放在一起，否则共享一套资源（连接池、JVM等）会互相影响。最后的建议是分为普通服务、报表服务、定时任务三个部分。这一决定与主流技术背道而驰，相当于降级。做出这样的决定后，小伙伴们都撇了撇嘴---以后出去打工不好吹了。但是解决办法是什么？最原始的方法，可以适应任何恶劣的环境，经得起客户的任何花招。这是公司目前的情况决定的。唯一的问题是，很多人只是这样做。结语每年都会看到很多很多传统行业的人想进互联网圈。许多外包和项目公司与传统公司没有什么不同。具体边界之前有过比较深入的比较。如果你刚好在这个行业，千万不要迷信互联网公司的技术栈，他们真的让人接受不了。互联网的挑战主要是流量，而你的挑战是成本。老板要的是快速完成工作，拿回货款，而不是系统的长期稳定。这时候你用的技术很花哨，但是没有人深入，到头来会一团糟。正是因为我对微服务的特殊理解，才建议这些公司不要采用微服务，这很可笑吧？当然，微服务很好，很吸引人，用来练习是没问题的，但是记住，练习差不多在系统上线之前，赶快跑起来吧。否则锅是你的。作者：味姐小姐姐编辑：陶佳龙来源：转载自公众号小姐姐的味道（ID：xjjdog）
