【微服务专题】微服务架构演进

前言
阅读对象
阅读导航
前置知识
笔记正文
- 一、系统架构的演变
- - 1.1 单体架构
  - 1.2 单体水平架构
  - 1.3 垂直架构
  - 1.4 SOA架构
  - 1.5 微服务架构
- 二、如何实现微服务架构
- - 2.1 微服务架构下的技术挑战
  - 2.2 微服务技术栈选型
  - 2.3 什么是Spring Cloud全家桶
  - 2.4 Spring Cloud Alibaba版本选择
学习总结

前言

事实上，我个人对单体到微服务架构的演进尽管能够理解，但总是觉得差点意思，所以这边在学习之余，顺便写个笔记总结一下，加深一下印象吧。

阅读对象

阅读导航

系列上一篇文章：《【微服务专题】SpringBoot自动配置简单源码解析》

前置知识

笔记正文

一、系统架构的演变

别看微服务架构牛逼哄哄的样子，但真要从市场上来说：没有最好的架构，只有最合适的架构。存在即合理。
通常来说，我们认为架构发展历史经历了这样一个过程：单体架构 -> 垂直架构 -> SOA面向服务架构 -> 微服务架构。
接下来，我们从每个架构的特点，以及遇到的问题、如何解决等角度来给大家介绍一下每个架构。

1.1 单体架构

基本介绍
单体架构嘛，我们普通Java程序员接触过最多的一种架构模式了。简单来说就是一个SpringBoot应用，通常来说，所有的业务功能都部署在一块，这样可以减少开发、部署和维护的成本。

特点
所有功能模块都在一个应用里面，一旦应用宕机、或者正常运维关闭启动期间，所有服务都不可用

架构图示
在这里插入图片描述
优点

项目架构简单，结构也简单，在项目不大的时候，开发运维成本较低

项目小的时候是这样，项目大的时候你就会戴上痛苦面具了

缺点
下面说的缺点，也正是这个架构在演进当中面临的挑战

全部功能集成在一个工程中，对于大型项目来讲不易开发和维护

我们公司现在的架构局部来说就是这样，ALL-IN-ONE，每次打包编译启动都要7、8分钟，好一点的机器也是5、6分钟。这基本注定了，你不能在高峰期重启服务，一旦重启就是生产事故

项目模块之间紧密耦合，单点容错率低
无法针对不同模块进行针对性优化和水平扩展

这一点我个人认为可能是最重要的一点。还是拿我公司现在的项目来说，某些模块其实负载特别大，但由于项目架构的问题，没办法精准分配流量、硬件资源等，多少是有点浪费的

不过，在单体架构的演进过程中，首先遇到的问题并非模块化问题，而是随着用户量越来越大，网站的访问量不断增大，导致后端服务器的负载越来越高！
还是拿我们公司举例：我们从17年刚开始踏足团餐领域的时候，没多少个客户，所以一台服务器就解决了。但是随着业务的扩张，我们全国已经有8000+的客户，分布在全国各地，无论是从硬件资源，还是运维部署来看，一台服务器肯定不行的。这时候，我们公司就开始了水平扩张的演进。

1.2 单体水平架构

严格来说还是属于单体架构，只不过做了水平拓展而已，架构图如下：
在这里插入图片描述
当然，随着业务深入，我们公司也开始了一些其他尝试。以前所有功能都写在一个工程目录下，迭代了6、7年之后，我的大佬们应该也无法忍受了，你懂的。五花八门的代码，别具一格的代码风格，使得维护、升级改造成本极高！所以，渐渐的，一些比较独特的业务也被抽离出来单独部署一台服务器，这种架构方式我们可以称之为：垂直架构。

1.3 垂直架构

基本介绍
所谓水平拓展：多个一摸一样内容的应用
所谓垂直拓展：简单来说专服专用。从业务的垂直领域进行拆分，减少业务的耦合度，以及降低单个war包带来的伸缩性困难问题

特点
专服专用

优点

系统拆分实现了流量分担，可以针对不同模块进行优化
方便水平扩展，负载均衡，容错率提高
系统间相互独立，互不影响，新的业务迭代时更加高效

缺点

服务之间相互调用，如果某个服务的端口或者IP地址发生改变。调用的系统得手动变化

这个我深有体会。由于只是简单的垂直架构，也没有接入熔断器之类的东西，所以其中一个环节出错，对调用方的影响是巨大的！特别是在日志不全，报错提示又不友好的前提下，排查问题想当麻烦

服务之间调用方式不统一，基于httpclient,webservice，接口协议不统一
搭建集群之后，实现负载均衡比较复杂。比如：内网负载，在迁移得时候会影响调用方的路由，导致线上故障
服务监控不到位

但其实在我们公司的垂直架构开发中，我个人还是遇到了一些很让人无奈的问题。诸如：

系统之间很多重复的业务，但由于彼此之间是独立的，逻辑无法完全共享
不同系统之间会产生各自的信息，有时候希望获得对方的信息，但这种信息获取又不是那么便捷，很多时候需要额外写接口传递。所以就造成这样的现象：明明都是同属于同一个公司的东西，但是彼此之间共享不便捷（软件架构领域称之为：信息孤岛）

基于上述这些缺点及问题，于是有人提出了SOA架构。

1.4 SOA架构

SOA（Service-Oriented Architecture），也就是面向服务的架构。在SOA中，会采用ESB（企业服务总线）来作为系统和服务之间的通信桥梁，ESB本身还提供服务地址的管理、不同系统之间的协议转化和数据格式转化等。调用端不需要关心目标服务的位置，从而使得服务之间的交互是动态的，这样做的好处是实现了服务的调用者和服务的提供者之间的高度解耦。
总的来说，SOA主要解决的问题是：

共享业务的重用
信息孤岛

特点

服务地址管理
协议转换
数据转换

架构图
在这里插入图片描述

优点

使用治理中心（ESB）解决了服务间调用关系的自动调节

缺点

服务间会有依赖关系，一旦某个环节出错会影响较大( 服务雪崩 )

引入了更多中间件，意味着系统复杂度会上升。比如引入redis、mq等，这两个玩意，在没有做高可用的情况下，任何一个崩溃了都会导致服务雪崩。

服务关系复杂，运维、测试部署困难

其实上面说的缺点咱也不知道这算不算缺点，百度是这么说的。但是不可否认的是，随着更多系统、中间件的引入，不可避免地增加了运维成本。

1.5 微服务架构

严格来说，微服务架构算是SOA架构的进一步优化，它更加强调服务的【彻底拆分】。面向服务（SOA）和微服务本质上都是服务化思想的一种体现。从架构图来看，微服务其实就是一个SOA下面包含多个SOA，然后最小的SOA就是一个微服务。
伴随着服务粒度的细化，会导致原本10个服务可能拆分成了100个微服务，一旦服务规模扩大就意味着服务的构建、发布、运维的复杂度也会成倍增加，所以实施微服务的前提是软件交付链路及基础设施的成熟化。
由于SOA和微服务两者的关注点不一样，造成了这两者有非常大的区别：

SOA关注的是服务的重用性及解决信息孤岛问题
微服务关注的是解耦，虽然解耦和可重用性从特定的角度来看是一样的，但本质上是有区别的，解耦是降低业务之间的耦合度，而重用性关注的是服务的复用
微服务会更多地关注在DevOps的持续交付上，因为服务粒度细化之后使得开发运维变得更加重要，因此微服务与容器化技术的结合更加紧密

微服务架构就是将每个具体的业务服务构成可独立运行的微服务，每个微服务只关注某个特定的功能，服务之间采用轻量级通信机制REST API进行通信。

优点

复杂度可控：通过对共享业务服务更细粒度的拆分，一个服务只需要关注一个特定的业务领域，并通过定义良好的接口清晰表述服务边界。由于体积小、复杂度低，开发、维护会更加简单
技术选型更灵活：每个微服务都由不同的团队来维护，所以可以结合业务特性自由选择技术栈
可扩展性更强：可以根据每个微服务的性能要求和业务特点来对服务进行灵活扩展，比如通过增加单个服务的集群规模，提升部署了该服务的节点的硬件配置
独立部署：由于每个微服务都是一个独立运行的进程，所以可以实现独立部署。当某个微服务发生变更时不需要重新编译部署整个应用，并且单个微服务的代码量比较小，使得发布更加高效
容错性：在微服务架构中，如果某一个服务发生故障，我们可以使故障隔离在单个服务中。其他服务可以通过重试、降级等机制来实现应用层面的容错

缺点

故障排查：一次请求可能会经历多个不同的微服务的多次交互，交互的链路可能会比较长，每个微服务会产生自己的日志，在这种情况下如果出现一个故障，开发人员定位问题的根源会比较困难
服务监控：在一个单体架构中很容易实现服务的监控，因为所有的功能都在一个服务中。在微服务架构中，服务监控开销会非常大，可以想象一下，在几百个微服务组成的架构中，我们不仅要对整个链路进行监控，还需要对每一个微服务都实现一套类似单体架构的监控
分布式架构的复杂性：微服务本身构建的是一个分布式系统，分布式系统涉及服务之间的远程通信，而网络通信中网络的延迟和网络故障是无法避免的，从而增加了应用程序的复杂度
服务依赖：微服务数量增加之后，各个服务之间会存在更多的依赖关系，使得系统整体更为复杂。假设你在完成一个案例，需要修改服务A、B、C，而A依赖B，B依赖C。在单体式应用中，你只需要改变相关模块，整合变化，再部署就好了。对比之下，微服务架构模式就需要考虑相关改变对不同服务的影响。比如，你需要更新服务C，然后是B，最后才是A，幸运的是，许多改变一般只影响一个服务，需要协调多服务的改变很少
运维成本：在微服务中，需要保证几百个微服务的正常运行，对于运维的挑战是巨大的。比如单个服务流量激增时如何快速扩容、服务拆分之后导致故障点增多如何处理、如何快速部署和统一管理众多的服务等

二、如何实现微服务架构

2.1 微服务架构下的技术挑战

微服务架构主要的目的是实现业务服务的解耦。随着公司业务的高速发展，微服务组件会越来越多，导致服务与服务之间的调用关系越来越复杂。同时，服务与服务之间的远程通信也会因为网络通信问题的存在变得更加复杂，比如需要考虑重试、容错、降级等情况。那么这个时候就需要进行服务治理，将服务之间的依赖转化为服务对服务中心的依赖。除此之外，还需要考虑：

服务的注册与发现
分布式配置中心
服务路由
负载均衡
熔断限流
分布式链路监控

这些都需要对应的技术来实现，我们是自己研发还是选择市场上比较成熟的技术拿来就用呢？如果市场上有多种相同的解决方案，应该如何做好技术选型？

2.2 微服务技术栈选型

业内比较主流的微服务解决方案进行分析，主要包括：

Spring Cloud Netflix
Spring Cloud Alibaba

毫无疑问，我们选择Spring Cloud Alibaba

2.3 什么是Spring Cloud全家桶

Spring Cloud提供了一些可以让开发者快速构建微服务应用的工具，比如配置管理、服务发现、熔断、智能路由等，这些服务可以在任何分布式环境下很好地工作。Spring Cloud主要致力于解决如下问题：

Distributed configuration，分布式配置
Service registration and discovery，服务注册与发现
Routing，服务路由
Service-to-service calls，服务调用
Load balancing，负载均衡
Circuit Breakers，断路器
Distributed messaging，分布式消息

需要注意的是，Spring Cloud并不是Spring团队全新研发的框架，它只是把一些比较优秀的解决微服务架构中常见问题的开源框架基于Spring Cloud规范进行了整合，通过Spring Boot这个框架进行再次封装后屏蔽掉了复杂的配置，给开发者提供良好的开箱即用的微服务开发体验。不难看出，SpringCloud其实就是一套规范，而Spring Cloud Netflix、Spring Cloud Alibaba才是Spring Cloud规范的实现。
在这里插入图片描述
Alibaba的开源组件在服务治理上和处理高并发的能力上有天然的优势，毕竟这些组件都经历过数次双11的考验，也在各大互联网公司大规模应用过。所以，相比Spring Cloud Netflix来说，SpringCloud Alibaba在服务治理这块的能力更适合于国内的技术场景，同时，Spring Cloud Alibaba在功能上不仅完全覆盖了Spring Cloud Netflix原生特性，而且还提供了更加稳定和成熟的实现