q397064399
2019-06-20 10:51:08 +08:00
在实际生产使用中有很大炒作嫌疑， 就目前我接触到很多在中小公司从业的同事朋友来说，
Micro Service 真的夸大其词了
第一大块，Micro Service 是有使用代价的，基础设施跟不上，在调试 /运维 /发布 /开发 /验证
等各个环节都是要大幅度降低生产效率的。
恰好 中小型公司对改进开发效率没有任何动力，
因为很多所谓的互联网公司，业务才是王道，各级开发领导都是背着业务开发任务指标的，
基本上很难有动力做这些基础设施的改进。
1.我知道的 目前就有 3 种 httpclient 在我们服务中使用 ，
其中还有一个 3 年前封装的半成熟的 httpclient 也在使用当中，既没有文档 又没有注释，
正确的使用方式全靠猜解跟参照过去的历史遗留代码。
2.模块化依赖做得很不合理，我不知道谁在哪里看了几篇 maven 的最佳实践，硬是要把 maven 默认的 scope 尽量换成 provided，虽然 Java 本身是一门静态语言，但实际上有很多动态特性，使用 provided 做 scope 很多时候导致动态序列化的时候 ClassNotFoundException，测试一方面无法保证所有的代码路径都被测试到，只能把这种依赖问题就被推迟了线上，目测未来要擦很多次屁股，本来 maven 推荐使用最短依赖路径版本来取胜，通过 exclude 来排除依赖冲突，到了我们这里就全变了。
3.服务间的接口不存在静态检查了，需要人工保证接口参数 /版本 一致，人这种东西，没有规章流程，就很容易出问题，遗漏是在所难免的，导致很多时候晚上发布，不同的团队在线上一起来修各种 BUG。
4.脱裤子放屁的事情太多，consumer 服务 监听消息队列 或者 task 服务 定时触发任务，然后又将消息的数据通过 http 调用 传回给 对应的业务服务，实际处理业务运算的仍然是 业务服务，中间加了一层脱裤子放屁的 task consumer 服务，task 配合的定时调度框架既无法在 task 服务中执行上下文中监视任务执行过程（因为真正执行业务代码的在 对应的业务服务里面 task consumer 没有 mapper 无法直接跟数据库打交道） task consumer 访问业务服务 通过 http 调用 经常直接超时，从而导致定时调度框架根本无法判断任务是否执行成功，最后导致定时任务调度框架的后台日志功能 完全变成摆设，如果想查看定时任务的执行结果 只能每天查看打印在阿里云的业务服务系统的日志。
第二大块，
1. 拆分不合理 导致调用网跟蜘蛛网一样混乱，拆分没有可行的原则，导致很多本应该拆分到对应服务的领域模型，全被美名其曰弄到基础服务里面了，实际上所谓的基础服务 既没有边界上下文 又没有领域定义，是个啥都能往基础服务里面装，结果将商品系统里面的 sku product 商品属性 全往基础服务里面装，整个商品系统服务 定价系统服务 成了一个空架子，每次干啥都要往基础服务里面取东西，而整个拆分的决策在一开始是非常不成熟的，最后由于各个系统调用的混乱的原因，基本上不太可能再对服务做拆分演化了，同之前的理由，由于业务压力，技术方面只能是继续腐烂下去，不存在改进的可能，开发人员只能在这种泥潭里面继续挣扎