一、微服务

1、什么是微服务？

微服务架构（通常简称为微服务）是指开发应用所用的一种架构形式。通过微服务，可将大型应用分解成多个独立的组件，其中每个组件都有各自的责任领域。在处理一个用户请求时，基于微服务的应用可能会调用许多内部微服务来共同生成其响应。在微服务架构中，每个微服务都是独立的服务，每个微服务都通过简单的接口与其他服务通信，以解决业务问题。

2、微服务产生的背景

随着互联网技术的发展，传统的应用架构已满足不了实际需求，微服务架构就随之产生。那么传统应用架构到底出了什么问题呢?接下来将从传统单体架构的问题开始，对为什么需要微服务架构进行详细讲解。传统单体应用架构都是模块化的设计逻辑，程序在编写完成后会被打包并部署为一个具体的应用。如下图所示：

单体应用架构，易于开发和调试，并且易于部署。在用户量不多时，此种架构方式完全可以满足需求，但随着用户人数的增加，一台机器已经满足不了系统的负载，此时就会考虑系统的水平扩展。通常情况下，只需要增加服务器的数量，并将打包好的应用拷贝到不同服务器(如Tomcat)，然后通过负载均衡器(如Apache、Nginx)就可以轻松实现应用的水平扩展。但是随着时间的推移，单应用架构会出现下面的问题，如下：

• 应用复杂度增加，更新、维护困难：一旦应用变的庞大而又复杂，那么开发团队将会面临很多问题，其中最主要问题就是这个应用太复杂，以至于任何单个开发者都很难进行二次开发或维护
• 影响开发效率：当一个应用越大时，启动时间就会越长。开发和调试的过程中，如果有很大一部分时间都要在等待中渡过，那么必然会对开发效率有极大的影响。
• 应用可靠性低：传统单体应用架构在运行时的可靠性比较低，当所有模块都运行在一个进程中时，如果任何一个模块中出现了一个Bug，可能会导致整个进程崩溃，从而影响到整个应用。

为了解决单体应用架构遇到的问题，引入了微服务架构，下面了解下微服务架构的优点

3、微服务的特性

自主性：可以对微服务架构中的每个组件服务进行开发、部署、运营和扩展，而不影响其他服务的功能。这些服务不需要与其他服务共享任何代码或实施。各个组件之间的任何通信都是通过明确定义的 API 进行的。
专用性：每项服务都是针对一组功能而设计的，并专注于解决特定的问题。如果开发人员逐渐将更多代码增加到一项服务中并且这项服务变得复杂，那么可以将其拆分成多项更小的服务。

4、微服务的优点

微服务架构具备下面这些优点，如下：

• 灵活扩展：通过微服务，您可以独立扩展各项服务以满足其支持的应用程序功能的需求。
• 敏捷性：微服务促进若干小型独立团队形成一个组织，这些团队负责自己的服务。各团队在小型且易于理解的环境中行事，并且可以更独立、更快速地工作。这缩短了开发周期时间。
• 轻松部署：微服务架构模式可以实现每个微服务独立部署，支持持续集成和持续交付。
• 弹性：服务独立性增加了应用程序应对故障的弹性。在整体式架构中，如果一个组件出现故障，可能导致整个应用程序无法运行。通过微服务，应用程序可以通过降低功能而不导致整个应用程序崩溃来处理总体服务故障。

5、微服务的缺点

微服务架构虽然逻辑设计上看是完美的，但就像积木搭建的华丽宫殿一样，经不起风吹草动。微服务架构虽然解决了旧问题，也引入了新的问题：

• 微服务架构整个应用分散成多个服务，定位故障点非常困难。
• 稳定性下降。服务数量变多导致其中一个服务出现故障的概率增大，并且一个服务故障可能导致整个系统挂掉。
• 服务数量非常多，部署、管理的工作量很大。
• 开发方面：如何保证各个服务在持续开发的情况下仍然保持协同合作。
• 测试方面：服务拆分后，几乎所有功能都会涉及多个服务。原本单个程序的测试变为服务间调用的测试。测试变得更加复杂。

6、Service Mesh

使用统一的微服务框架有一个比较严重的问题：框架更新成本很高。每次框架升级，都需要所有应用服务配合升级。另一种抽象公共代码的方法是直接将这些代码抽象到一个反向代理组件。每个服务都额外部署这个代理组件，所有出站入站的流量都通过该组件进行处理和转发。这个组件被称为Sidecar。Sidecar只负责网络通信。还需要有个组件来统一管理所有sidecar的配置。在Service Mesh中，负责网络通信的部分叫数据平面（data plane），负责配置管理的部分叫控制平面（control plane）。数据平面和控制平面构成了Service Mesh的基本架构。Sevice Mesh相比于微服务框架的优点在于它不侵入代码，升级和维护更方便。它经常被诟病的则是性能问题。

参考文档：https://www.zhihu.com/question/65502802