什么是微服务？

1.什么是微服务？

简单的说微服务是一种架构上的设计风格，它的主旨是将原本独立的系统拆分为一个一个小型服务，这些小型服务在独立的进程中运作，服务之间通过 HTTP 的 RESTful API 进行通信协作。被拆分的小型服务围绕着系统中某一个或者某一耦合度较高的业务功能进行构建，并且每个服务独立维护自己的数据存储、业务开发、自动化测试以及独立部署机制。由于有了轻量级的通信协作，所以这些微服务可以通过不同的语言来编写。

2.与单体系统的区别

在传统的单体项目中，所有的业务逻辑都在同一个系统中开发测试部署，相较与微服务系统单体项目在前期开发测试部署维护相较比较简单，但随着企业的发展，需要增加不同的业务模块，会导致单体项目日渐臃肿，单体项目的弊端逐渐展现：

a.往往增加或修改一个小功能，为了部署上线需要暂停整个服务。

b.单体项目往往耦合度高，无法对模块系统容量进行评估。

c.前期开发维护简单，随着系统的发展，维护成本将变得越来越大，且难以控制。

为了解决单体项目的弊端，微服务应运而生了。我们将系统拆分为多个小型服务，这些服务能够独立开发部署。由于每个服务在独自的进程中运行，在部署上有稳固的边界。这样每个服务的更新不会影响其他服务。由于独立部署，我们能准确的对独立的项目进行评估其瓶颈。

3.微服务面临的挑战

a.运维的挑战

       在微服务架构中，由于拆分为多个独立的小型服务，运维人员需要维护的进程数量大大增加。有条不紊的进行维护难度增加，运维过程需要更多的自动化，这就要求运维人员具备一定的开发能力，传统的运维人员很难适应。

b.接口的一致性

       虽然我们拆分成了多个服务，但是业务上的耦合不会改变。只是从单体项目上的耦合变成了服务间的通信依赖。如果我们对原有的接口改变了，那么交互方也需要同步更改来进行发布，以确保接口能正常调用。因此我们需要更严格的接口和版本管理，或者严格的遵循开闭原则。

c.分布式的复杂性

       由于拆分为多个服务运行在不同的进程，它们只能通过通信来进行交互协作，同时带来了问题，例如：网络延迟、分布式事务、异步消息等。

---

尽管微服务有很多优点和缺点，但是其强大自动化部署和敏捷开发的优点等被广大开发者和架构师青睐。

---

由于微服务没有一个统一的标准和规范，每个架构师都有各自理解，所以 Martin Fowler 在 Microservices 一文中，提炼了微服务的九大特性，指导大家进行设计架构。

1.服务组件化

在微服务中需要我们对服务进行组件化分解

2.按业务组建团队

微服务团队建议按照业务线进行拆分

3.做“产品”的态度

每个项目团队都要对产品的生命周期负责，而不是以开发和交付为目标。

4.智能端点和哑管道

微服务架构不在同一个进程中通信，而是通过RPC方式进行调用，会导致微服务间产生繁琐的通信，使得系统更加糟糕，所以我们需要更加粗粒度的通信协议。

a.RESTful API 的消息通信协议

b.通过轻量级消息总线进行通信。类似 RabbitMQ 等一些提供异步消息交换的中间件。

5.去中心化治理

通过采用轻量级的契约定义接口，使得服务本身对具体的平台不在敏感。

6.去中心化管理数据

微服务中我们都希望每个服务有各自的数据库，但是由于分布式服务本身实现难度就非常大，所以为微服务架构中，我们强调各服务之间是“无事务”的调用，而对于数据的一致性，只要求数据在最终的处理状态是一致的即可。若在过程中发现错误，通过补偿机制来进行处理，使得错误数据也能最终一致性。

7.基础设施自动化

自动化测试、自动化部署

8.容错设计

在微服务架构中，快速检测出故障源并能自动恢复服务是必须设计和考虑的

9.演进式设计

通过上面的特征，可以看出实现微服务的困难是非常大的，所以一般建议前期单体项目进行开发后期逐渐抽成微服务。