微服务架构你或许正在滥用
战术 三连 求 求 求 做个人吧，
微服务架构 真不适合一般的团队跟业务，
假如你的技术团队 没有 运维团队 中台开发 跟若干个 业务团队开发。这些业务团队有自己的运维 产品经理 前后开发团队分配。请不要滥用 所谓的 “微服务” 架构
1、首先不得不说这种架构是解决了 超大型团队 以及超大型 可拆分项目 提供了更便捷的解决办法。 其实同样也带来了性能的损失。跟维护成本翻倍成长。尽管我们使用长连接，但是它还是不如旧事库依赖管理。
2、我们抛开性能这一块先别说， 那就是维护成本会急剧的加大， 如果你的人手不够情况下，你很多时候就是没事给自己找事做。
3、不得不说这种架构你可以学到很多东西，但是不希望你拿公司的项目来试刀。它的成本代价太大， 没几个公司给你匹配同等位的人数， 最后你一个人不仅是 运维 开发 架构 测试， 你还是几个团队。 最后的东西都是一样，甚至性能更差。、、
来自被 所谓的 “微服务” 架构受害人。 2-3个人 去维护40多个项目。 你便知道是什么灾难性的， 甚至连日志跟自动部署都没搭建好、
我只想奉劝各位大佬，别在一味的吹捧 “微服务”架构。让一些人迷失了方向。 不考虑自身的业务 跟自身的团队实力，以及资金输出 就 听风是风，听雨便是雨、
做为每个开发人 鼓励去学习新的技术，新的概念，这没错， 但是最后 我希望大家明白一句 ： 技术是服务于业务的。 如果脱离了服务业务，你的技术将一文不值、
所以，或许你也行 正在 滥用 微服务
求求 你们 所谓的 掌托人 做个人吧， 你的每一个决定 应该从公司多维考虑，而不是一味的用技术思维考虑。 最后你又不愿意付出同等的 价值 去 盘活。
本来2分钟完成的事，你非要用2个小时来完成，最后感觉自我良好。 有这时间，你去学习新的技术，或者优化下你的项目。它不是更香吗？
不要再滥用所谓的 “架构” ，做任何东西 应该从简单到复杂。从你的业务 团队水平 资金支出 慢慢平滑升级 才是上上策。
淘宝10年前也是简简单单的东西，经过10多年的洗礼磨练才达到 如今的 架构，因为人力支出跟技术已经同等了，
妖魔鬼怪就不应该冷静的思考下自己的 多维问题吗？
为什么老想 10W 的支出 用别人 100W甚至 1000W 东西呢？