01-如何理解微服务(Microservice)?

背景分析

单体应用架构

在传统的单体应用系统架构中，一般分为三个部分，即数据库端、服务应用端和前端展现端，如图所示：

在业务发展初期，由于所有的业务逻辑在一个应用中，开发、测试、部署都比较容易。但是，随着业务的发展，系统为了应对不同的业务需求会不断为单体应用增加不同的业务模块。久而久之，不断扩充的业务需求导致单体应用的系统越来越庞大臃肿。此时，单体应用的问题也逐渐显现出来，由于单体应用是一个“整体”，往往修改一个小的功能，为了部署上线就会影响到其他功能的运行。

对于业务而言，往往不同模块对系统资源的要求不也尽相同，而单体应用各个功能模块因为无法分割，也就无法细化对系统资源的需求。所以，单体应用在初期是比较方便快捷，但是随着业务的发展，维护成本会越来越大，且难以控制。

云原生应用分析

云原生的概念最早开始于2010年，主要用于描述一种和云一样的系统行为应用的编写，比如分布式的、松散的、自服务的、持续部署与测试的。当时提出“云原生”是为了能构建一种符合云计算特性的标准来指导云计算应用的编写。

导致了“云原生”概念的诞生的因素，主要有几个方面：

云计算平台的普及。
虚拟化技术的发展。
敏捷开发的出现，DevOps的应用缩短了发布周期

云平台具有很好的可扩展性，为了利用这一点，云原生应用由多个小而独立的模块组成,如图所示：

基于这些独立模块构建的服务架构，就叫做微服务。

微服务简介

微服务定义

微服务架构（MSA）的基础是将单个应用程序开发为一组小型独立服务，这些独立服务在自己的进程中运行，独立开发和部署。

这些服务使用轻量级 API 通过明确定义的接口进行通信。这些服务是围绕业务功能构建的，每项服务执行一项功能。由于它们是独立运行的，因此可以针对各项服务进行更新、部署和扩展，以满足对应用程序特定功能的需求。

微服务是分布式系统中的一种流行的架构模型，它并不是银弹，所以，也不要寄希望于微服务构架能够解决所有的问题。微服务架构主要解决的是如何快速地开发和部署我们的服务，这对于一个能够适应快速开发和成长的公司是非常必要的。同时，微服务设计中有很多很不错的想法和理念，通过学习微服务架构我们可以更快的迈向卓越。

微服务特性

自主性

可以对微服务架构中的每个组件服务进行开发、部署、运营和扩展，而不影响其他服务的功能。这些服务不需要与其他服务共享任何代码或实施。各个组件之间的任何通信都是通过明确定义的 API 进行的。

专用性

每项服务都是针对一组功能而设计的，并专注于解决特定的问题。如果开发人员逐渐将更多代码增加到一项服务中并且这项服务变得复杂，那么可以将其拆分成多项更小的服务。

微服务的优势

敏捷性

微服务促进若干小型独立团队形成一个组织，这些团队负责自己的服务。各团队在小型且易于理解的环境中行事，并且可以更独立、更快速地工作。这缩短了开发周期时间。您可以从组织的总吞吐量中显著获益。

扩展性

通过微服务，您可以独立扩展各项服务以满足其支持的应用程序功能的需求。这使团队能够适当调整基础设施需求，准确衡量功能成本，并在服务需求激增时保持可用性。

轻松部署

微服务支持持续集成和持续交付，可以轻松尝试新想法，并可以在无法正常运行时回滚。由于故障成本较低，因此可以大胆试验，更轻松地更新代码，并缩短新功能的上市时间。

代码可重用性

将软件划分为小型且明确定义的模块，让团队可以将功能用于多种目的。专为某项功能编写的服务可以用作另一项功能的构建块。这样应用程序就可以自行引导，因为开发人员可以创建新功能，而无需从头开始编写代码。

较好的弹性设计

服务独立性增加了应用程序应对故障的弹性。在整体式架构中，如果一个组件出现故障，可能导致整个应用程序无法运行。通过微服务，应用程序可以通过降低功能而不导致整个应用程序崩溃来处理总体服务故障。

总结(Summary)

在本章节中，讲述了微服务诞生的背景，传统单体架构的劣势，同时，基于云原生技术的的发展，微服务架构诞生。基于微服务架构，可以更好的，灵活的处理客户端的请求并提高系统的可靠性，可扩展性。