Warner不看好微服务的原因，大致是以下几个：
- 整个团队在一个大型单体应用中工作，相比微服务会少很多精力去考虑服务之间调用失败的情况。
- 随着企业架构的发展，分布式系统越来越多（包括了基础服务的微服务和应用系统的微服务），如果过多的应用系统微服务，将会导致更多的稳定性风险。
- 为了适配基础服务微服务和应用系统微服务带来的风险，会建设非常多冗余的系统，这些系统最后会表现为债务。
Warner建议单体到微服务的顺序是：单体 -> 服务 -> 微服务。
Warner认为，一家5-50人规模的公司，只需要单体，而无需使用微服务。
当企业规模变大时，企业遇到的不是技术问题，而是组织上的挑战。
过多的微服务会导致权限边界问题。同时，为了处理过多微服务带来的问题，需要引入更多的工具。
代码过多是债务，服务过多会带来稳定性和体验的风险，这些都是开销和风险。
因此Warner鼓励企业不盲目选择微服务，尽可能延长单体应用使用时间。
微服务体系的搭建，应该从基础设施开始，而不是上层应用。
应该尽可能选择库，而不是微服务。
微服务的优点很多人认为是简单，但大部分人其实并不了解如何正确的设计他们。
经验表明，一个设计糟糕的单体架构，几乎总好过设计糟糕的微服务架构。
良好的架构应该始于模块化，拆分单体的第一步是考虑基于特性功能分割代码和数据，这部分工作不一定必须通过微服务实现，在单体中做模块划分也是可以的。
从单体转变到微服务，可以先在数据库模式中识别功能，依照边界将实际的库表分组。
进而，将拆分的数据拆到不同的微服务架构上。
github过去优先抽取的服务是身份验证与授权。
uber在2020年放弃了微服务，转而采用宏服务。
uber采用微服务期间，每个微服务承接了很小的需求或功能，以至于一个人维护很多微服务的情况。这些冗杂的微服务带来了新的复杂度和挑战，比如监控、测试、持续集成、持续交付、服务SLA保证等问题。
后续uber对于微服务的划分，采用了基于某一项业务功能，团队由5~10个工程师维护，这样的服务被称作微服务。
看到这里不自觉的思考，大家所说的微服务是一件事吗？
比如uber的意思是每个功能点都拆成一个微服务？不然怎么会出现一个人负责好几个微服务的情况。
其实这种情况在很多公司很常见，比如我见过一个团队20个人，里面有20 服务的情况，最后就会导致一系列文中所说的问题。
比如边界问题，经常一个需求来了之后，看下来这个需求在好几个服务都可以做，但是总感觉只在一个服务下做又不合适，结果这个很简单的需求被拆成好几个技术需求，提给不同的服务，每个服务只做非常小的功能点代码的改造，把一个非常简单的需求搞的巨复杂。
一边做着这样边界不清晰的划分，另一边又在聊着降本增效，看着就很魔幻。
另一个问题是稳定性问题，因为服务多了，势必需要做一些稳定性保障，服务多了，同样一件事就需要做很多次，调动很多人，成本巨大，一件挺简单的限流或者降级改造，因为服务多了往往需要推几个月。
服务多了，想做异地多活的调度就更复杂了，因为你需要考虑所有微服务之间的流量调度现状，同样的一个异地流量调度改造，微服务拆分合理与否效果差别非常大。
总之，我觉得合适的才是最好的，合适需要考虑团队能力、业务发展阶段、组织沟通形式，这个不是一个纯技术问题，在技术之外的成本，如服务器成本、沟通成本、协作成本都是需要考虑的。
写到这里，不得不佩服贝佐斯，他不是技术出身，但最初很好的定义了SOA架构，通过API做数据共享，两个披萨团队做服务拆分。
