【01】微服务架构分析及发展

1. 微服务简介

1.1 系统架构演变历程

1.1.1 单体应用架构

• 互联网早期，网站的应用流量比较小，只需要一个应用。将所有功能代码都部署在一起就可以，这样可以减少开发、部署和维护的成本；
• 例如：一个电商系统，里面包含了用户管理、商品管理、订单管理、消息模块等等多个模块，我们会把它们做成一个web项目，然后部署到一台tomcat服务器上。
  
• 优点：
  • 项目架构简单，对于小型项目来说，开发成本低；
  • 项目部署在一个节点上，易维护；
• 缺点：
  • 全部功能集成在一个工程中，对于大型项目来说是不易开发和维护的；
  • 项目模块之间高度耦合，单点容错率低；
  • 无法针对不同模块进行针对性优化和水平扩展；

1.1.2 垂直应用架构

• 随着用户访问量的逐渐增大，单体应用只能依靠增加节点来应对，但这时候会发现并不是所有的模块都会有比较大的访问量。以上面的电商为例，影响最大的是用户和订单模块，对于消息模块来说并没有很大的影响。
• 那么此时，我们希望多增加几个订单模块，而不增加消息模块，在单体应用上是做不到的，因此，垂直应用就此诞生了。
• 所谓的垂直应用架构，就是将原来的一个应用拆分成几个互不相干的应用，以提升效率。例如，可以将上面的电商单体应用拆分成：
  • 电商系统（用户管理、商品管理、订单管理）
  • 后台管理系统（用户管理、订单管理、客户管理）
  • CMS系统（广告管理、营销管理）
• 这样拆分后，一旦用户访问量变大，只需要增加电商系统的节点就行，无需增加后台和CMS的节点；
  
• 优点：
  • 系统拆分实现了流量分担，解决了并发问题，而且可以针对不同模块进行优化和水平扩展；
  • 一个系统的问题不会影响到其他系统，提高了容错率；
• 缺点：
  • 系统之间相互独立， 无法相互进行调用；
  • 系统之间相互独立， 会存在重复的开发任务；

1.1.3 分布式架构

• 当垂直应用越来越多，重复的业务代码也会越来越多。这时候，我们就思考可不可以将重复的代码抽取出来，做成统一的业务层作为独立的服务，然后由前端控制层调用不同的业务层服务。
• 这就产生了新的分布式系统架构。它将把工程拆分成表现层和服务层两个部分，服务层中包含业务逻辑。表现层只需要处理和页面的交互，业务逻辑都是调用服务层的服务来实现。
  
• 优点：
  • 抽取公共的功能为服务层，提高代码复用性；
• 缺点：
  • 系统间耦合度变高，调用关系错综复杂，难以维护；

1.1.4 SOA架构

• 在分布式架构下，当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心对集群进行实时管理。此时，用于资源调度和治理中心(SOA Service Oriented Architecture)是关键。
  
• 优点：
  • 使用治理中心（ESB\dubbo）解决了服务间调用关系的自动调节；
• 缺点：
  • 服务间会有依赖关系，一旦某个环节出错会影响较大( 服务雪崩 )；
  • 服务关系复杂，运维、测试部署困难；

1.1.5 微服务架构

• 微服务架构在某种程度上是面向服务的架构SOA继续发展的下一步，它更加强调服务的"彻底拆分"。
  
• 微服务架构与SOA架构的不同：
  • 微服务架构比 SOA架构粒度会更加精细，让专业的人去做专业的事情（专注），目的提高效率，每个服务之间互不影响，微服务架构中，每个服务必须独立部署，微服务架构更加轻巧，轻量级。
  • SOA 架构中可能数据库存储会发生共享，微服务强调独每个服务都是单独数据库，保证每个服务于服务之间互不影响。
  • 项目体现特征微服务架构比 SOA 架构更加适合与互联网公司敏捷开发、快速迭代版本，因为粒度非常精细。
• 优点：
  • 服务原子化拆分，独立打包、部署和升级，保证每个微服务清晰的任务划分，利于扩展；
  • 微服务之间采用Restful等轻量级http协议相互调用；
• 缺点：
  • 分布式系统开发的技术成本高（容错、分布式事务等）；
  • 各个微服务进行分布式独立部署，当进行模块调用的时候，复杂度更高；

1.2 背景分析

• 先分析一下单体应用。所谓单体应用一般是基于maven创建一个工程，然后基于SpringBoot，Spring，Mybatis框架进行整合。接下来再写一堆dao、mapper、service、controller，再加上一些的配置文件，有可能还会引入redis、elasticsearch、mq等其它项目的依赖，开发好之后再将项目打包成一个jar包/war包。然后再将包扔到类似tomcat这样的web服务中，最后部署到公司提供给你的Linux服务器上。
• 再针对服务提供的访问端口（例如8080端口）发起http请求，请求会由tomcat直接转交给Spring Web组件，进行一层一层的代码调用。对于这样的设计一般适合企业的内部应用，访问量不大，体积比较小，5人以内的团队即可开发和维护。
• 但对于一些大型互联网项目，假如需要10人以上的开发和维护团队，仅频繁的创建代码分支，编写业务功能，然后合并分支，就会出现很多代码冲突。每次解决这些大量的代码冲突，就会效率低下。基于这样的背景微服务诞生了。
• 在微服务架构涉及中，建议超出需要10人开发和维护的项目要进行系统拆分。就是把大系统拆分为很多小系统，几个人负责一个服务，这样每个服务独立的开发、测试和上线，代码冲突就少了，每次上线就回归测试自己的一个服务即可，测试速度快了，上线是独立的，只要向后兼容接口就行了，不需要跟别人等待和协调，技术架构和技术版本的升级，成本降低，更加灵活。
  

1.3 什么是微服务

• 微服务架构(MSA)的基础是将单个应用程序开发为一组小型独立服务，这些独立服务在自己的进程中运行，独立开发和部署。
• 微服务其实是一种架构风格，我们在开发一个应用的时候这个应用应该是由一组小型服务组成，每个小型服务都运行在自己的进程内；小服务之间通过HTTP的方式进行互联互通。
  
  这些服务使用轻量级API通过明确定义的接口进行通信，也是围绕业务功能构建的，每项服务执行一项功能。由于它们是独立运行的，因此可以针对各项服务进行更新、部署和扩展，以满足对应用程序特定功能的需求。
  
  总之，微服务是分布式系统中的一种流行的架构模型，它并不是银弹，所以，也不要寄希望于微服务构架能够解决所有的问题。微服务架构主要解决的是如何快速地开发和部署我们的服务，这对于一个能够适应快速开发和成长的公司是非常必要的。同时，微服务设计中有很多很不错的想法和理念，通过学习微服务架构我们可以更快的迈向卓越。

2.微服务解决方案

2.1 SpringCloud Netflix 解决方案

2.1.1 概述

对于微服务架构，几乎所有的大公司走的都是自研路线。例如，国内最初的典型代表就是基于阿里的Dubbo进行实现的，后来国外的netflix公司将他们内部的微服务技术架构进行了开源，在互联网行业产生了很大的影响力，然后接着就被整合到了spring社区，变成了spring cloud项目。

2.1.2 核心组件分析

Spring Cloud这个项目里面整合的基本上都是netflix公司的微服务相关组件，例如借助eureka做注册中心、feign和ribbon结合实现远程过程调用和负载均衡、zuul做网关、hystrix做熔断，用zipkin和sleuth做链路监控，stream做消息中间件集成，contract做契约测试支持，然后跟spring security配合的做安全认证，跟k8s配合的进行容器化操作等。Spring cloud将这些组件打包集成在一起，进行微服务架构实现，最初在国外比较有市场，几年前在国内也火了，大量公司都开始拥抱spring cloud，尤其是中小型公司。

2.1.3 解决方案架构设计

基于Spring Cloud实现的一代微服务架构，解决方案设计架构如下图所示：

说明：在现阶段SpringCloud netflix公司的这套微服务解决方案，官方的很多组件，现在已经不提供维护了。
相关概念：
网关：请求入口。
注册中心：例如，入驻某个平台需要进行注册信息。
熔断：例如，因电流过大跳闸或者保险丝烧了。
限流：类似车被限号。

2.2 Spring Cloud Alibaba解决方案

2.2.1 概述

Spring Cloud Alibaba 是Spring Cloud的一个子项目，致力于提供微服务开发的一站式解决方案。此项目包含开发分布式应用微服务的必需组件，方便开发者通过 Spring Cloud 编程模型轻松使用这些组件来开发分布式应用服务。依托 Spring Cloud Alibaba，您只需要添加一些注解和少量配置，就可以将 Spring Cloud 应用接入阿里微服务解决方案，通过阿里中间件来迅速搭建分布式应用系统。

2.2.2 核心组件分析

1. 服务限流降级： 默认支持 WebServlet、OpenFeign、RestTemplate、Spring Cloud Gateway, RocketMQ 限流降级功能的接入，可以在运行时通过控制台实时修改限流降级规则，还支持查看限流降级 Metrics 监控。
2. 服务注册与发现：基于Spring Cloud 服务注册与发现标准，借助Nacos进行实现，默认还集成了 Ribbon 的支持。
3. 分布式配置管理：基于Nacos支持分布式系统中的外部化配置，配置更改时自动刷新。
4. 消息驱动能力：基于Spring Cloud Stream 为微服务应用构建消息驱动能力。
5. 分布式事务： 使用 @GlobalTransactional 注解， 高效并且对业务零侵入地解决分布式事务问题。
6. 分布式任务调度：提供秒级、精准、高可靠、高可用的定时（基于 Cron 表达式）任务调度服务。同时提供分布式的任务执行模型，如网格任务。网格任务支持海量子任务均匀分配到所有 Worker上执行。
   

2.3 基于Spring Cloud Alibaba实现的微服务架构图

总之，微服务是一个架构设计方式，此架构中的每个服务(service)都是针对一组功能而设计的，并专注于解决特定的问题。如果开发人员逐渐将更多代码增加到一项服务中并且这项服务变得复杂，那么可以将其拆分成多项更小的服务。接下来进行独立的开发、测试、部署、运行、维护。进而更好，更灵活的处理客户端的请求并提高系统的可靠性，可扩展性。