微服务

微服务是由Martin Fowler与James Lewis于2014年共同提出，需要了解细节的读者可以阅览https://martinfowler.com/articles/microservices.html。其实Martin先生并没有给出明确的微服务定义，根据其描述，微服务的定义可以概括如下︰微服务架构是一种使用一系列粒度较小的服务来开发单个应用的方式;每个服务运行在自己的进程中;服务间采用轻量级的方式进行通信（通常是HTTP API)﹔这些服务是基于业务逻辑和范围，通过自动化部署的机制来独立部署的，并且服务的集中管理应该是最低限度的，即每个服务可以采用不同的编程语言编写，使用不同的数据存储技术。现在微服务架构已经不是一个新概念了，很多业界前沿互联网公司的实践表明，微服务是一种渐进式的演进架构，是企业应对业务复杂性，支持大规模持续创新行之有效的架构手段

一、传统的整体式架构（单体）

传统的整体式架构都是模块化的设计逻辑，如数据展示（Views）、应用程序逻辑控制（Controller）、业务逻辑（Service）和数据访问对象（Dao），程序在编写完成后被打包部署为一个具体的应用。如图所示：

 

系统的扩展性

如果要对系统进行水平扩展，通常情况下，只需要增加服务器的数量，并将打包好的应用拷贝到不同的服务器，然后通过负载均衡器（Nginx）就可以轻松实现应用的水平扩展。

整体式架构的缺点

• 应用复杂度增加，更新、维护困难。
• 易造成系统资源浪费。
• 影响开发效率。
• 应用可靠性低。
• 不利于技术更新。

二、面向服务的架构SOA（Service-Oriented Architecture）

SOA的思路是把应用中相近的功能聚合在一起，以服务的形式提供出去。如图所示：

 

缺点

虽然SOA解决了整体式架构中的问题，但多数情况下，SOA中相互独立的服务仍然会部署在同一个运行环境中。和整体式架构类似，随着业务功能的增多，SOA的服务会变得越来越复杂。本质上看，整体式架构的问题并没有因为使用SOA而变得更好。

三、微服务架构

微服务架构是一种系统架构的设计风格。与传统的单体式架构（ALL IN ONE）不同，微服务架构提倡将一个单一的应用程序拆分成多个小型服务，这些小型服务都在各自独立的进程中运行，服务之间使用轻量级通信机制（通常是 HTTP RESTFUL API）进行通讯。通常情况下，这些小型服务都是围绕着某个特定的业务进行构建的，每一个服务只专注于完成一项任务并把它做好 ，即“专业的人做专业的事”。每个服务都能够独立地部署到各种环境中，例如开发环境、测试环境和生产环境等，每个服务都能独立启动或销毁而不会对其他服务造成影响。这些服务之间的交互是使用标准的通讯技术进行的，因此不同的服务可以使用不同数据存储技术，甚至使用不同的编程语言。

三、微服务架构 vs 单体架构

在当今的软件开发领域中，主要有两种系统架构风格，那就是新兴的“微服务架构”和传统的“单体架构”。单体架构是微服务架构出现之前业界最经典的软件架构类型，许多早期的项目采用的也都是单体架构。单体架构将应用程序中所有业务逻辑都编写在同一个工程中，最终经过编译、打包，部署在一台服务器上运行。
在项目的初期，单体架构无论是在开发速度还是运维难度上都具有明显的优势。但随着业务复杂度的不断提高，单体架构的许多弊端也逐渐凸显出来，主要体现在以下 3 个方面：

• 随着业务复杂度的提高，单体应用（采用单体架构的应用程序）的代码量也越来越大，导致代码的可读性、可维护性以及扩展性下降。
• 随着用户越来越多，程序所承受的并发越来越高，而单体应用处理高并发的能力有限。
• 单体应用将所有的业务都集中在同一个工程中，修改或增加业务都可能会对其他业务造成一定的影响，导致测试难度增加。

由于单体架构存在这些弊端，因此许多公司和组织都开始将将它们的项目从单体架构向微服务架构转型。

异同点	微服务架构	单体架构
团队	微服务架构可以将传统模式下的单个应用拆分为多个独立的服务，每个微服务都可以单独开发、部署和维护。每个服务从设计、开发到维护所需的团队规模小，团队管理成本小。	单体架构的应用程序通常需要一个大型团队，围绕一个庞大的应用程序工作，团队管理的成本大。
数据存储方式	不同的微服务可以使用不同的数据存储方式，例如有的用 Redis，有的使用 MySQL。	单一架构的所有模块共享同一个公共数据库，存储方式相对单一。
部署方式	微服务架构中每个服务都可以独立部署，也可以独立于其他服务进行扩展。如果部署得当，基于微服务的架构可以帮助企业提高应用程序的部署效率。	采用单体架构的应用程序的每一次功能更改或 bug 修复都必须对整个应用程序重新进行部署。
开发模式	在采用微服务架构的应用程序中，不同模块可以使用不同的技术或语言进行开发，开发模式更加灵活。	在采用单体架构的应用程序中，所有模块使用的技术和语言必须相同，开发模式受限。
故障隔离	在微服务架构中，故障被隔离在单个服务中，避免系统的整体崩溃。	在单体架构中，当一个组件出现故障时，故障很可能会在进程中蔓延，导致系统全局不可用。
项目结构	微服务架构将单个应用程序拆分为多个独立的小型服务，每个服务都可以独立的开发、部署和维护，每个服务都能完成一项特定的业务需求。	单体架构的应用程序，所有的业务逻辑都集中在同一个工程中。

四、微服务的特点

• 服务按照业务来划分，每个服务通常只专注于某一个特定的业务、所需代码量小，复杂度低、易于维护。
• 每个微服都可以独立开发、部署和运行，且代码量较少，因此启动和运行速度较快。
• 每个服务从设计、开发、测试到维护所需的团队规模小，一般 8 到 10 人，团队管理成本小。
• 采用单体架构的应用程序只要有任何修改，就需要重新部署整个应用才能生效，而微服务则完美地解决了这一问题。在微服架构中，某个微服务修改后，只需要重新部署这个服务即可，而不需要重新部署整个应用程序。
• 在微服务架构中，开发人员可以结合项目业务及团队的特点，合理地选择语言和工具进行开发和部署，不同的微服务可以使用不同的语言和工具。
• 微服务具备良好的可扩展性。随着业务的不断增加，微服务的体积和代码量都会急剧膨胀，此时我们可以根据业务将微服务再次进行拆分；除此之外，当用户量和并发量的增加时，我们还可以将微服务集群化部署，从而增加系统的负载能力。
• 微服务能够与容器（Docker、k8s）配合使用，实现快速迭代、快速构建、快速部署。
• 微服务具有良好的故障隔离能力，当应用程序中的某个微服发生故障时，该故障会被隔离在当前服务中，而不会波及到其他微服务造成整个系统的瘫痪。
• 微服务系统具有链路追踪的能力。