microservice-dark-cloud

对微服务的切分总是来自与业务范围

通过对传统的投资预算和团队管理的变革，将微服务作为产品运营建立以业务结果导向的稳定产品团队

Product over Project , 构建稳定的团队是实现微服务的的管理变革

当服务不在是一个技术组件，而是一个业务服务时，所面临的技术问题并非在微服务的场景中得到体现

分布式通信框架，地址无关的服务注册和发现，智能路由和编排系统早在上古时代实现了一遍又一遍， RPC, SOA 都是具体的体现

反模式的阴云总是在轮回似的发生

开发者对强类型RPC代码的依恋，虽然历史告诉我们RPC不能为分布式通信提供足够好的封装，伪装成本地方法的调用客户端往往成为api设计不良的温床

细粒度的频繁调用，缺少缓存和容错处理，IDL生成客户端会导致依赖耦合, 每次升级都需要升级N个相关服务

一个可能的解决方法是通过RESTful HATEOAS模式 ,通过对返回的增强，实现对api 变更的自动化跟踪

快速的序列化和反序列化，类型安全和IDE的智能提示，是开发人员经常“发明”rpc的潜在动力

“开发人员的便利性是否真的胜过正确性，可扩展性，性能，关注点分离，可扩展性和意外复杂性？” – Vinoski

ESB 将异构应用链接在一起起到关键作用，但接入的服务越来越多，分配的职责更多的被加入，数据的剪切转换，

服务发现，智能路由，监控治理，分布式事务等问题将ESB变成单点梦魔，导致对ESB系统的难以测试和版本控制

所以微服务发出了”智能终端哑管道”的呐喊，我们需要的是一个不那么智能的代理来处理可靠消息传递，将灵活的逻辑交给服务本身去编排

在典型的微服务系统中，通过Unix 哲学将负载均衡，服务注册发现，分布式跟踪等各司其职

但在竞争的情况下，厂商不断将更多的功能放到其中间件中

如果API Gateway 开始处理数据转换和业务逻辑编排，那么就可以认为这又是一个轮回的ESB, 最终导致梦魔般的单点问题

而只是通过横切的方式处理鉴权，限流等则没有问题

技术的发展，但还在使用旧思维，导致通过新技术一遍遍的实现旧的反模式