微服务的核心思路就在于将业务能力封装成独立的松耦合的服务。通过这样一组服务，构建企业内的能力生态系统。除了能满足当前应用的需要之外，也为未来可能的新应用提供了紧实的基础。
在《拆完中台再拆微服务》中也阐述了微服务是为了提升程序效能和团队效能。
当提到微服务时，总会想到各种各样的好处：
1、使大型的复杂应用程序可以持续交付和持续部署
2、每个服务都相对较小并容易维护
3、服务可以独立部署
4、服务可以独立扩展
5、微服务架构可以实现团队的自治
6、更容易实验和采纳新的技术
7、更好的容错性
当然，没有一项技术是“银弹”。
微服务架构也存在一些显著的弊端和问题：
1、服务的拆分和定义是一项挑战
2、分布式系统带来的各种复杂性，使开发、测试和部署变得更困难
3、当部署跨越多个服务的功能时需要谨慎地协调更多开发团队
4、开发者需要思考到底应该在应用的什么阶段使用微服务架构
近些年，反对微服务的声音越来越多。
在twitter上有个很热门的贴子：
twitter.com/xuwenhao/status/1593469165892820992 作者显明的数落了微服务的种种不是。为了更方便你了解作者的看法，我简单罗列下：
1、微服务的适应场景非常有限。这么多巨头互联网公司的核心业务逐渐微服务化，的确是在特定的历史时期和场景下的解决方案。
2、大型系统的开发，核心的挑战其实只有一个，就是“控制复杂性”。微服务不会减小复杂性，只会转移复杂性，它天然是为了解决极度复杂的计算、存储问题，中小规模系统其实是根本不需要的，至少在成为大型系统之前。
3、在系统开发上，控制复杂性的方式，可以用三个关键词来描述，那就是“抽象”、“封装”和“复用”。
4、服务化的第一个挑战：是“服务”并不是无状态的，“服务”也绑定了数据。以电商业务为例。商场生成订单，必在服务内持久化下来。然后，这个订单会发给到订单履约系统，也会持久化下来。然后两边都有可能触发订单状态的变更，商场用户可能取消订单，履约系统可能因为商品缺货也取消订单。两边都需要有对应的接口和实现，去完成这样的状态同步。这个过程中，就容易引入数据不一致的问题。
5、第二个挑战：因为是不同的服务，就会面临“向前兼容”的问题，不同的系统并不是完全同步迭代的。而已经发布的服务，意味着对外有了明确的协议承诺。在服务发布新版本的时候，必须要确保向前兼容。
6、第三个挑战：因为服务化划分了明确的边界，系统更容易变成异构的，更容易引入更多的技术栈。并且有些功能，会在两个不同的语言、框架下各实现一遍，也容易进一步放大之前所说的业务数据不一致的第一个挑战
三种典型的伪微服务
在James Lewis 和 Martin Fowler的名作《微服务》中，将微服务定义为一种架构风格，并总结了它的九种特质：
1、通过服务实现组件化
2、服务按照业务能力划分组织
3、服务以产品而不是项目研发
4、逻辑集中在服务中，编排简单
5、每个服务自主决策（技术栈、语言等等）
6、每个服务自主管理数据（不强制使用统一数据源）
7、基础设施自动化
8、将服务失败当作常态纳入设计考量
9、演进式设计（不求一步到位）
在实现中，如果对上面的特质理解出现偏差，就会出现三种典型的伪微服务风格
1、分布式服务
服务按照业务能力划分组织
微服务中的服务应该以业务能力为粒度。这间接回答了“微服务到底多微合适”，既不是单纯的技术能力（比如查询、获取系统时间），也不是完整的应用，而是用以支撑构建应用的业务能力。
通常所说的“恰当粒度”是在业务与实现两个维度上平衡的结果。并不会存在“只从单一维度入手，越怎么样就越好”这么简单粗暴的结论。所以微服务并不是越小越好，当小到不能表示业务能力，就不再是微服务了。
如果不顾及服务是否按照业务能力划分组织，就是一种典型的伪微服务模式。被称之为分布式服务。当然分布式服务并不是反模式，它有其特有的用处，只不过它并不是微服务而已。
2、微工作组
服务以产品而不是项目研发
这主要是从生命周期角度看，产品和项目的差异体现在团体结构和生命周期上。
产品的生命周期分为初始、稳定、支持和结束生命几个阶段。那么产品的不同版本，可能处在不同的生命周期中。所以产品团队需要在同一时间内，支持多个处在不同生命周期的产品版本。而项目通常假设只有唯一产物，随着项目生命周期的进项，项目化服务一直在改变。
因此产品化服务的生命周期，实际上相当于承诺在产品生命周期内，服务是不变的。也就是说只要1.0不结束生命，那么我们就可以一直使用它。哪怕发布了1.5、2.0、3.0，只要1.0满足我的需要，并且还在生命周期内，作为消费者，可以无视你的后续版本。
微服务需要服务间不仅仅在接口上松耦合，还在要生命周期上松耦合。也就是微服务可以自主发布，其他服务不应该受到影响。产品化是实现这一点的根本途径。
如果服务缺乏产品化生命周期，那就会产生一组在生命周期上紧密耦合的服务，从而完全丧失微服务的意义。随着服务数量变多，这种生命周期的耦合还会带来难以承受的沟通成本。
3、傻服务
逻辑集中在服务中，编排简单
逻辑越在服务中集中，所需要的编排就越简单，通常通过RESTful API或者轻量的消息机制即可完成。
如果服务中的逻辑简单，那就会有大量的逻辑泄露到编排逻辑中，此时就需要使用复杂的编排工具辅助我们工作。
选择编排复杂的逻辑，听越来很有道理：既然我们希望在不同场景下复用服务，那么总有一些需要改变的订制代码，我们需要将它们与服务本身分离。分离之后，就能通过编排引擎，帮助我们在不同的场景下重用这些服务
但按照这个逻辑下去，服务往往会变成对于数据的CRUD，然后大量的逻辑存在于编排引擎中，这也是典型的伪微服务。像傻服务一样。
总结
其实任何技术都可以说它既不是银弹也不是哑弹。就是优势与缺点并存。我们需要权衡的是在什么样的阶段引入什么样的技术来帮我们更好更快地解决问题。
