微服务最早被提出是作为SOA的一种轻量化的补救方案而被提出来的

微服务的概念

微服务是一种通过多个小型服务的组合，来构建的单个应用的架构风格，这些服务会围绕业务能力而非特定的技术标准来构建。各个服务可以采用不同的编程语言、不同的存储技术、运行在不同的进程之中。服务会采用轻量级的通讯机制和自动化的部署机制来实现通讯与运维。

九个核心业务与技术特征

1. 围绕业务能力构建

​ 有怎样的结构、规模、能力的团队，就会产生出对应结构、规模、能力的产品。

2.分散治理

​ 微服务开发团队有着直接对服务运行质量负责的责任，也应该有不受外界干预，掌控服务各方面能力的权力，能选择与其他服务异构的技术来实现自己的服务。

3.通过服务来实现独立自治的组件

​ 通过远程服务而非类库来提供功能，从而得到组件的隔离与自治能力。

4.产品化思维

​ 避免把软件开发看作是要去完成某种功能，而是要把它当作是一种持续改进、提升的过程

5.数据去中心化

​ 数据应该按领域来分散管理、更新、维护和存储。有时候一致性问题也可能是必须要付出的代价

6.轻量级通讯机制

​ 如果服务需要上面的某一种功能或能力，那就应该在服务自己的Endpoint上解决，而不是在通讯管道上一揽子处理。RESTful风格的通讯方式，在微服务中就是比较适合的。

7.容错性设计

​ 承认服务会出错，接收服务总会出错的现实。有了这个认识的前提，在设计微服务的时候就要求有自动的机制能对其依赖的服务进行快速的故障检测，持续出错的时候可以进行自动的隔离，在服务恢复好之后重新联通。

​ 可靠的系统由不会出错的服务来组成，这就是微服务最大的价值所在

8.演进式设计

​ 承认服务会被淘汰。一个良好的设计，应该是能够报废的，而不是指望着它长久。

9.基础设施自动化

​ 服务一多，靠人工来运维这根本就是不可能的事情。所以会要依赖大量的基础设施来自动化完成

注意：以上9个是一个合理的微服务系统展示出来的内、外在表现，它能够指导你该如何应用微服务架构，而不能作为一种强加于系统中的束缚来看待。

这么自由的微服务理念咋不上天呢？以前提到的那个分布式问题就不存在了吗？还是得一个个的解决。于是各种技术框架纷纷出现。比如像Eureka、Consul、Nacos、Zookeeper、Etcd用来解决服务发现的技术、像Dubbo、Thrift、gRPC用来解决服务通讯的技术，真的是层出不穷。更甚至还有springcloud之类的全家桶，真的是给开发人员带来巨大的便利。

便对架构的要求也越来越高了。架构者如何在各种决策之间权衡能力也变得至关重要起来！

那有没有一种即可以得到微服务自由的权力、还能专注于自己的业务，同时又不用费力去解决分布式带来的问题的解决方案呢？

思考题

你所负责的产品是不是基于微服务的？如果是，它符合微服务的9个特征吗？如果不是，你的产品适合微服务架构吗？你所在的企业、团队适合引入微服务吗？