微服务的缺点

我只服气 53 楼

我只服气 53 楼

我只服气 53 楼

@guolaopi 首先确定主表，肯定先查历史订单，再查店铺信息

传输层的数据和 orm 肯定不一样，图省事吧 orm 的结构拿过来肯定会有问题

至于改底层结果，肯定会造成 Gateway 的一些改动，这个无可厚非，即使单体应用也一样，不过建议数据的 merge 在最上层做。

其实微服务的核心就是抽象业务，而非抽象技术。每个服务都是一个单独的业务服务就好了。

@gemini767
get 到了，我就理解成 soa 里企业总线做的事微服务里多调几个服务来搞定。

小团队来说 微的优秀也是极好的适合增长的时候不用换轮子
当然业务不发展没需求 一把梭也没啥问题

大团队来说 个人感觉 超过一定规模的肯定有基础部门
配套组件这类 自然而然需要拆分 没什么好不好

大点都是 soa paas saas ？

仿佛在我的世界里没有出现过微服务，至少还没有真正体会过。

@gemini767 那如果是店铺要自己的历史订单呢?分页呢？

@chenqh 消费者的历史订单和店家的历史订单有区别么 :)

@gemini767 你说你在 64 楼的回复是消费者的历史订单？ 那我就针对你 64 楼来讲
1. 如何分页？ 比如每页 10 条数据, 先从历史订单里面取 10 条？ 在 filter 店铺信息？
2. 假如有一个管理后台，产品提出，需要根据 用户名来查询 历史订单怎么做？ 关键还要有分页！

店铺信息的问题，也就是跨服务列表的问题，你们都不觉得是产品设计的问题吗？为什么一定要在列表中显示店铺信息？不能鼠标悬停或者点击后显示店铺详细信息吗？

我认为是核心问题是缺少规范。
这基本上所团队协作型任务都要面临的问题。灵活的代价是降低开发速度，进一步受限于架构。这里我只想谈一下缺点，因为克服了缺点，不就万事大吉了嘛。

网络调用过多
微服务的本质就是调来调去，这么个没错，如果你说的是那种 http call 的话，的确造成一些不必要的延时是没办法的

技术栈太过灵活
灵活是双刃剑啦

难于应对连表查询的需求
没错，里面还可能不止一种数据库，要查询怎么都麻烦

核心应用崩溃会导致大面积瘫痪
熔断，限流我觉得并不能有效的防治应用奔溃不能用的事实，最多也就是让你损失的不那么多而已。

运维成本增加
能不手动的就不要手动，实际上设立了统一 CI/CD 风格后只有好处没有坏处，写代码也更有信息

接口风格不一致
Convention over configuration，这点也是因为技术栈的不统一导致的很多问题，PHP 有自己的想法，Java 也有自己的想法。

微服务的出发点是好的，对于前端人员来说，其实需要的想要的结果，以及统一格式的返回，至于后面发生了什么，怎么协作的，他们并不需要去 care，你用 56 种语言都没有问题，他们要的就是你统一格式的 json 而已。
还有我一直不认为只用 SpringCloud 这种厚重的东西写出来的能叫做微服务。
对于服务提供的后端来说，有一个统一风格的 数据库 ORM DSL 也是一个很好的解决方案，因为那些业务就是查询来查询去，插来插去，这个时候当前后端不能统一的时候，就需要一个 MiddleMan 来干这些脏活累活，就是所谓的中台，提供聚合好的东西。

没有银弹的，Serverless 也不是。

@chenqh 还是要确定主表是什么，你要查询历史订单，不管什么条件，都是在历史订单里查询完，然后在 merge 店铺信息，不会你的订单里连店铺的 id 都没存吧？那是一个完成的订单系统么？

关于分页，不知道纠结点在那？ limit offset 不能用？

大部分公司 把业务模块，分清楚就够了

一般的公司只会一般的微服务，也就是把几个业务拆成几个独立的应用，然后在 k8s 中运行，就算微服务。
但是真正的微服务，有一套完整配置管理、服务发现、熔断器、智能路由、微代理、控制总线、一次性令牌、全局锁、领导选举、分布式会话、集群状态等等。

@xuanbg
虽然我也喜欢怼产品，但你说这个有点过不去了，
什么叫：“为什么非要在列表中显示店铺信息？”
就是有这个需求呗，不能啥都甩给产品设计有问题吧（凭良心
难不成因为这个不干了换公司？

码农一枚，个人觉得不能为了微服务而微服务，微服务是大型系统为了解耦、降低复杂度，各人负责各人的那一块就好，真到了要用微服务的级别你说的这些都不是问题，有真正的底层公共组件，有代码规范，有专业运维。好多在做微服务完全就是歪货。。。完全用不着而且加大了工作量

@gemini767 那根据店铺名字来查找分页呢？