【微服务】软件架构的演变之路

layout: post
title: 【微服务】软件架构的演变之路
date: 章于 2024-08-16 11:18:56 发布
author: 'zhangtao'
header-img: 'img/post-bg-2015.jpg'
catalog: false
tags:

Java
微服务
Dubbo
微服务
架构
云原生

单体式架构的时代
- 单体式架构(Monolithic)
- 优点
- 缺点
- 适用场景
- 单体式架构面临诸多问题
集群
- 优点
- 缺点
- 适用场景
- 搭建集群后面临诸多问题
- 改进后的架构
垂直架构
- 优点
- 缺点
分布式架构
- 产生
- 分布式架构
分布式和集群的区别
- 集群是个物理形态，分布式是个工作方式
- 提升效率的方式不同
新的问题
- 场景假设
- 优化方向
SOA 架构
- 特点
新的问题2
- SOA架构的问题
- 优化方向
微服务架构
- 什么是微服务
- 微服务架构的特征
- 优点
- 缺点
- 微服务架构面临的挑战
- - 技术挑战
微服务 VS SOA
- 1.通讯协议
- 2.服务拆分
- 3.项目迭代
架构演变
主流的微服务框架
官网
- Dubbo
- Spring Cloud
- Spring Cloud Alibaba

{#_1}单体式架构的时代

宽带不足：1993年前后；网络普及率少
项目类型：以内部管理系统为主，项目不需要对外开放，对安全性和稳定性的要求是不高的。例如：OA、CRM、ERP
内容或资讯：内容主要由一些媒体、政府、公司等发布，对于网民来说，更多的是被动的接收

{#Monolithic_8}单体式架构(Monolithic)

单体式架构就是将所有业务场景中的表示层、业务逻辑层和数据访问层放在一个工程中，最终经过编译、打包为war包或jar包，部署在一台服务器上。
通俗的说法：如果一个war包或者jar包里面包含一个应用的所有功能，则是单体式架构。
早期的SSH和SSM项目大多是单体式架构的项目

{#_12}优点

架构简单、运维简单。开发成本低，开发周期短

{#_14}缺点

系统启动慢，一个进程包含了所有的业务逻辑，涉及到的启动模块过多，会导致系统的启动、重启时间周期过长;
系统错误隔离性差、可用性差，任何一个模块的错误均可能造成整个系统的宕机;
可伸缩性差：系统的扩容只能对整个应用扩容，成本高。不能做到对某个功能点进行扩容;
技术栈受限：只能使用1种开发语言；

{#_19}适用场景

适用于业务不复杂、访问量较小的项目
例如：政府项目、管理系统、crm客户关系管理系统

{#_24}单体式架构面临诸多问题

{#1_25}1.宽带提速，网民增多

时间的年轮来到2004年，随之到来的WEB2.0时代，实现的ADSL拨号上网，宽带提速，最高可以达到8M，用户量也就不断增加，一些门户网站也开始活跃，项目就需要考虑安全性和稳定性，如果服务器发生宕机，则整个应用也随之崩溃

{#2Web20_27}2.Web2.0时代的特点

Web2.0模式下的互联网应用具有以下显著特点：去中心化、开放、共享。

用户分享。在Web2.0模式下，可以不受时间和地域的限制分享各种观点。用户可以得到自己需要的信息也可以发布自己的观点。
信息聚合。信息在网络上不断积累，不会丢失。
以兴趣为聚合点的社群。在Web2.0模式下，聚集的是对某个或者某些问题感兴趣的群体，可以说，在无形中已经产生了细分市场。
开放的平台，活跃的用户。平台对于用户来说是开放的，而且用户因为兴趣而保持比较高的忠诚度，他们会积极的参与其中。

{#_34}问题描述

产品最终的核心是产品的长期运行，作为公司，肯定希望这个产品被越来越多的人使用，这样才能创建更大的价值。对于整个技术架构来说，可能会面临以下挑战：

用户量增多，访问量不断增大，导致后端服务器的负载越来越高
用户量增多，产品需要满足不同用户的需求来留住用户，使得业务场景越来越多并且越来越复杂。
业务场景越多越复杂，意味着war包或jar包中的代码量会持续上升，耦合度也会越来越高。后期的代码维护和版本发布也会很困难。

{#_39}优化方向

通过横向添加服务器，把单台变成多台机器的集群；
按照业务维度把项目切割成多个项目，减少业务的耦合度，以及降低单个war包或jar包带来的伸缩性困难的问题。

{#_43}集群

在单体架构的基础上去搭建集群。如果一台服务器发生宕机，其他服务器可以继续运行，同时多台服务器也能分担大量用户访问的压力

集群就是单机的多实例，在多个服务器上部署多个服务，每个服务就是一个节点，这些节点的集合就叫做集群。

{#_47}优点

操作简单，容易部署，在搭建集群之后，可以提升项目的稳定性，并且并发量增加，也可以承受住。

{#_49}缺点

每个节点负载相同（耦合度高），每个具体业务的访问量可能差异很大，比如美团外卖美食外卖的访问量一定大于鲜花外卖的访问量，这就造成了资源浪费

{#_51}适用场景

单机处理到达瓶颈的时候，你就把单机复制几份，这样就构成了一个"集群"。集群中每台服务器就叫做这个集群的一个"节点"，所有节点构成了一个集群。每个节点都提供相同的服务，那么这样系统的处理能力就相当于提升了好几倍。

集群部署，它是把相同应用复制到不同服务器上，但是逻辑功能上还是单体应用

{#_55}搭建集群后面临诸多问题

{#_56}用户请求问题

用户的请求到底要发送到哪台服务器上，如何保证请求平均的分发给不同的服务器，从而缓解用户量增加的压力。

{#_58}用户的登录信息

编写项目时，如果用户登录成功了，将用户的标识放到Session域中，在搭建集群之后如何实现数据共享问题

{#_60}数据查询

当数据量特别庞大时，如果还直接去数据库查询，速度很慢，如何提升查询效率。

为了解决上述的问题，需要使用到的三门技术：

Nginx - 解决用户请求分发，负载均衡
Redis - 解决数据共享并实现缓存功能
ElasticSearch \ solr- 解决搜索数据的功能

{#_69}改进后的架构

{#_71}垂直架构

{#_83}产生

随着项目的不断迭代,新老功能之间需要相互交互,服务器和服务器之间是需要通讯的。我们无法直接实现通讯，怎么解决？
项目一般是分为三层的,Controller,Service,Dao。导致程序变慢的重灾区一般是service和Dao,在搭建集群时,确实针对三层都搭建集群，效果不是很好，怎么解决？
为了解决上述的各种问题架构从垂直架构演变到了分布式架构. 实现了模块之间的通讯

{#_87}分布式架构

分布式架构（Distributed Service Architecture，DSA）就是将一个完整的系统，按照业务功能，拆分成一个个独立的子系统，在分布式结构中，每个子系统就被称为"服务"。这些子系统能够独立运行在web容器中，它们之间通过RPC方式通信。

{#_90}分布式和集群的区别

{#_101}场景假设

场景1：假设用户执行下单操作，系统的处理逻辑是先去库存子系统检查商品的库存，如果库存充足的情况下才会提交订单，那么这个检查库存的逻辑是放在订单子系统中还是库存子系统中呢？这些业务场景的逻辑可能会被重复创建，从而产生冗余的业务代码。能不能把这些共享业务逻辑抽离出来形成可重用的服务呢？
场景2：在一个集团公司下有很多子公司，每个子公司都有自己的业务模式和信息沉淀，各个子公司之间不进行交互和共享。由于各个子公司之间信息不是互联互通的，彼此之间形成了信息孤岛，使得价值无法最大化

{#_104}优化方向

把一些通用的、会被多个上层服务调用的共享业务提取成独立的基础服务，并且可以重用。

{#SOA__106}SOA 架构

{#_171}主流的微服务框架
--|: