点击联系发帖人为了世界和平与社会和谐贯彻愛与正义。本文章大部分内容是劝退行为不适合以下几类人员阅读，请自觉出门左拐：
- 有钱或烧的起钱的公司员工或领导完全无所谓這么一个情况
- 需要用微服务这个概念忽悠客户做为一点商业噱头者
微服务这玩意在前几年莫名的突然流行了起来，而我本人也是趁着时代嘚浪潮在领导英(er)明(bi)的指导下，组成一个3人临时小团队对微服务相关的一系列技术进行了追逐，并为公司搭建了一整套微服务技术架构时至今日依然被使用中。而我也早已经从当初所就职的公司出来自己创了一波业，饿死在了梦想的路上然而，现在微服务的浪潮已經过去在拖垮了一部分公司后，越来越多公司开始清醒过来又开始了对数据中台新一波追逐的过程。
时至今日微服务相关的技术发展已经愈加繁荣昌盛，做微服务的也依然比比皆是回想往事，偶感所得砖也搬的有些累了，顺手写出来消磨消磨时间同时也给一些准备或正在做微服务技术的人或公司一点不成熟的建议。
不知道如何起个头这个对理科生实在是太难了，干脆就讲个真实的故事片段吧
前几年的某一天，公司的产品设计师发现最初的产品设计原型遗漏了一处非常重要的属性需要修改数据库表结构增加一个新的字段。這个事情就本身来讲可以算作是在原有基础上的一个扩展，一个小小的改动至少程序本身不需要干推倒重来这件事吧。
但问题出现了因为产品设计的划分，一共有5个团队参与其中包含了AI研发团队、算法团队、知识库研发团队、Potal研发团队、C端数据采集团队，一共上下將近50个左右参与从C端数据开始，连讨论带排计划安排带修改等花了几天时间。然后C端开始对接微服务环境中间通过了一层转换，变為微服务提供至微服务的环境下又花了几天时间修改。完了之后再通知AI团队和算法团队，服务接入情况对其进行调试和修改，又花叻几天时间期间因为各种非技术的原因，来来回回折腾了好几次后总算是将这个修改给改好了。然而时间将近过去了半个月。是的你没听错，数据库新增一个字段值就花掉了这么多时间。我们不讨论公司沟通模式是否有问题也不讨论员工是不是磨洋工是否高效率，或者是不是技术实现有问题等等我只能说当时的参与人员，大部分全是985、211、硕士、博士清华北大复旦这样的段位问题基本不会出現在这里，就算有问题还能50个高材生都弄错？这件事情的本身数据经过层层传递，对接的各个环节根本没有那么容易的去简化和优囮它的过程，且都是必要的
这根本不是微服务我想象中应该成为的样子，然而事实上就这样了那么问题出现在哪里呢？
现在暂且不談微服务。假如现在你正在使用你日常最熟悉的SSH之类的框架，你告诉我数据库新增一个属性字段，这点改动你需要花多少时间能改好当然，不考虑特别复杂的统计之类的情况等在最强码农的手里，你抽根烟的功夫就完事了慢的，怎么也不会超过一天吧
杠精登场：在你举的例子中，你这完全是两码事么这能比较么？
我：友军别开枪！是的，我也一样非常赞同你的观点
总结一下，其实我想说嘚意思是如果你想做微服务实现，你一定要好好思考一下以下几个问题：
- 公司的技术实力及人力物力资源是否足以完成与及时响应解决微服务实现过程中出现的所有问题
- 所需要使用微服务实现的项目，是否有必要一定要使用微服务项目不使用微服务是不是就做不好了？
- 产品的设计是否有必要设计成微服务才可以实现的样子，是否有硬性需求一定要将业务打散再组合
- 兄弟，你确定网络上随便扒拉几篇文章搭建个框架就能解决分布式事务的问题了吗你确定一招鲜能吃遍天？！
领导：你管劳资劳资就要用微服务，微服务好微服务棒，微服务顶呱呱响亮亮劳资死也要死在微服务的路上，你给劳资爬 ...
我：领导硬汉领导牛批！
