2.微服务及相关框架

1.微服务框架，微服务好处

　　微服务（MicroServices），我们可以从字面上去理解，即“微小的服务”：
　　（1） 所谓“服务”，其实指的是项目中的功能模块，它可以帮助用户解决某一个或一组问题，在开发过程中表现为 IDE中的一个工程或 Moudle。
　　（2） “微小”则强调的是单个服务的大小，主要体现为以下两个方面：

• 微服务体积小，复杂度低：一个微服务通常只提供单个业务功能的服务，专注于做好一件事。
• 微服务团队所需成员少：一般情况下，一个微服务团队只需要8到10名人员（开发人员2到5名）即可完成从设计、开发、测试到运维的全部工作。

 

2.微服务架构

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

 

3.微服务架构 vs 单体架构

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

（1）随着业务复杂度的提高，单体应用的代码量也越来越大，导致代码的可读性、可维护性以及扩展性下降。

（2）用户越来越多，程序所承受的并发越来越高，而单体应用处理高并发的能力有限。

（3）单体应用将所有的业务都集中在同一个工程中，修改或增加业务都可能会对其他业务造成一定的影响，导致测试难度增加。

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

4.微服务的特点 

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

 

5.微服务框架

　　微服务架构是一种系统架构风格和思想，想要真正地搭建一套微服务系统，则需要微服务框架的支持。随着微服务的流行，很多编程语言都相继推出了它们的微服务框架，下面我们就来简单列举下。

Java 微服务框架     

• Spring Cloud：它能够基于 REST服务来构建服务，帮助架构师构建出一套完整的微服务技术生态链。
• Dropwizard：用于开发高性能和 Restful 的 Web 服务，对配置、应用程序指标、日志记录和操作工具都提供了开箱即用的支持。
• Restlet：该框架遵循RST架构风格，可以帮助Java开发人员构建微服务。
• Spark：该框架支持通过Java 8和Kotlin创建微服务架构的应用程序。
• Dubbo：由阿里巴巴开源的分布式服务治理框架。

 

Spring Cloud 常用组件

Spring Cloud 包括Spring Cloud Gateway、Spring Cloud Config、Spring Cloud Bus等近20个服务组件，这些组件提供了服务治理、服务网关、智能路由、负载均衡、熔断器、监控跟踪、分布式消息队列、配置管理等领域的解决方案。
 
Spring Cloud 的常用组件如下表所示。

Spring Cloud 组件	描述
Netflix Eureka	Spring Cloud Netflix 中的服务治理组件，包含服务注册中心、服务注册与发现机制的实现。
Netflix Ribbon	Spring Cloud Netflix 中的服务调用和客户端负载均衡组件。
Netflix Hystrix	人称“豪猪哥”，Spring Cloud Netflix 的容错管理组件，为服务中出现的延迟和故障提供强大的容错能力。
Netflix Feign	基于 Ribbon 和 Hystrix 的声明式服务调用组件。
Netflix Zuul	Spring Cloud Netflix 中的网关组件，提供了智能路由、访问过滤等功能。
Gateway	基于Spring 5.0，Spring Boot 2.0和Project Reactor等开发的网关框架，它使用Filter链的方式提供了网关基本功能，如安全、监控/指标和限流等。
Config	Spring Cloud 的配置管理工具，支持使用Git存储配置内容，实现应用配置的外部化存储，并支持在客户端对配置进行刷新、加密、解密等操作。
Bus	Spring Cloud 的事件和消息总线，主要用于在集群中传播事件或状态变化，以触发后续的处理，例如动态刷新配置。
Stream	Spring Cloud 的消息中间件组件，它集成了Apache Kafka和RabbitMQ等消息中间件，并通过定义绑定器作为中间层，完美地实现了应用程序与消息中间件之间的隔离。通过向应用程序暴露统一的Channel通道，使得应用程序不需要再考虑各种不同的消息中间件实现，就能轻松地发送和接收消息。
Sleuth	Spring Cloud 分布式链路跟踪组件，能够完美的整合 Twitter的 Zipkin。