什么是微服务什么是微服务架构（微服务的优缺点）

什么是微服务什么是微服务架构（微服务的优缺点）一句话总结：微服务是 SOA 发展出来的产物，它是一种比较现代化的细粒度的 SOA 实现方式。微服务是细粒度的SOA组件，它们是关注点更窄的轻量级服务。微服务推崇执行的标准（例如HTTP）是人们广泛了解并共同使用的。我们可以通过选择合适的语言或工具来构建某个组件（微服务），除了技术栈与服务规模之外，在SOA与微服务之间还有一个更大的区别：领域模型。在一个基于微服务的软件中，每个微服务应该在本地存储自身管理的数据，并将领域模型分别隔离到单个服务中。而在面向 SOA 的软件中，数据往往存储在单个大型的数据库中，服务之间会共享领域模型。微服务就是将一个单体架构的应用按业务划分为一个个的独立运行的程序即服务，它们之间通过 HTTP 协议进行通信（也可以采用消息队列来通信，如 RabbitMQ，Kafaka 等），可以采用不同的编程语言，使用不同的存储技术，自动化部署（如 Jenkins）减少人为控

一、什么是微服务？

Martin Fowler 是这样解释微服务概念的：

In short the microservice architectural style is an approach to developing a single application as a suite of small services each running in its own process and communicating with lightweight mechanisms often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services which may be written in different programming languages and use different data storage technologies.

翻译如下：

简而言之，微服务架构风格是一种将单个应用程序作为一套小型服务开发的方法，每种应用程序都在自己的进程中运行，并与轻量级机制（通常是HTTP资源API）进行通信。 这些服务是围绕业务功能构建的，可以通过全自动部署机制独立部署。 这些服务的集中管理最少，可以用不同的编程语言编写，并使用不同的数据存储技术。

微服务就是将一个单体架构的应用按业务划分为一个个的独立运行的程序即服务，它们之间通过 HTTP 协议进行通信（也可以采用消息队列来通信，如 RabbitMQ，Kafaka 等），可以采用不同的编程语言，使用不同的存储技术，自动化部署（如 Jenkins）减少人为控制，降低出错概率。服务数量越多，管理起来越复杂，因此采用集中化管理。例如 Eureka，Zookeeper 等都是比较常见的服务集中化管理框架。

微服务是一种架构风格。一个大型的复杂软件应用，由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好的完成该任务。

二、微服务优点

• 测试容易
• 可伸缩性强
• 可靠性强
• 跨语言
• 协同开发
• 方便系统迭代

三、微服务缺点

• 运维成本高，部署项目多
• 接口兼容版本问题
• 分布式系统的复杂性
• 分布式事务

四、SOA vs 微服务

面向服务架构（SOA）是一种用于设计软件的伟大原则。在 SOA 中，所有组件都是独立自主的，并能为其他组件提供服务。大体上，SOA与微服务架构是非常相像的。那么它们之间的区别到底是什么呢？微服务是细粒度的 SOA 组件。换句话说，某单个 SOA 组件可以被拆成多个微服务，而这些微服务通过分工协作，可以提供与原 SOA 组件相同级别的功能，如下图所示。

微服务是细粒度的SOA组件，它们是关注点更窄的轻量级服务。微服务推崇执行的标准（例如HTTP）是人们广泛了解并共同使用的。我们可以通过选择合适的语言或工具来构建某个组件（微服务），除了技术栈与服务规模之外，在SOA与微服务之间还有一个更大的区别：领域模型。在一个基于微服务的软件中，每个微服务应该在本地存储自身管理的数据，并将领域模型分别隔离到单个服务中。而在面向 SOA 的软件中，数据往往存储在单个大型的数据库中，服务之间会共享领域模型。

一句话总结：微服务是 SOA 发展出来的产物，它是一种比较现代化的细粒度的 SOA 实现方式。

五、dubbo vs Spring Cloud

• Spring 全家桶 用起来很舒服，只有你想不到，没有它做不到。
• Dubbo 很多国内的企业还在用，可以支持 RESTful 风格的 API，调用远程 API 像调用本地 API 一样，同时其基于接口的方式增加了服务间的耦合。

六、总结

• Dubbo 由于是二进制的传输，占用带宽会更少
• SpringCloud 是 http 协议传输，带宽会比较多，同时使用 http 协议一般会使用 JSON 报文，消耗会更大
• Dubbo 的开发难度较大，原因是 Dubbo 的 jar 包依赖问题很多大型工程无法解决
• SpringCloud 的接口协议约定比较自由且松散，需要有强有力的行政措施来限制接口无序升级
• Dubbo 的注册中心可以选择 ZooKeeper Redis Nacos 等多种，SpringCloud 的注册中心可以用 Eureka Consul 等
• 从系统结构简易程序：SpringCloud 的系统结构更简单、“注册 SpringMvc = SpringCloud”，而 Dubbo 各种复杂的 url，protocol，register，invocation，dubbofilter，dubboSPI，dubbo序列化......
• 从性能：Dubbo 的网络消耗小于 SpringCloud，但是在国内 95% 的公司内，网络消耗不是什么太大问题，如果真的成了问题，通过压缩、二进制、高速缓存、分段降级等方法，很容易解决。
• 这是SpringCloud微服务架构教学文档，如需SpringCloud微服务 spring全家桶 项目实战教程和配套资料，请私信或留言评论。