SpringBoot

微服务(一)——单体架构 VS 微服务架构

Nick · 1月18日 · 2021年 · 本文3064字 · 阅读8分钟372

单体架构 VS 微服务架构

单体架构

1. 什么是单体架构

微服务(一)——单体架构 VS 微服务架构-左眼会陪右眼哭の博客
    一个工程对应一个归档包(war),这个war包 包含了该工程的所有功能。我们成为这种应用为单体应用,也就是我们常说的单体架构。具体描述: 就是在我们的一个war包种,聚集了各种功能以及资源,比如JSP,JS,CSS等。

2. 单体架构优缺点总结

2.1 优点
 1. 架构简单明了,所有功能都是基于内部调用,不涉及跨域跨进程调用。
 2. 开发、测试、部署简单

2.2 缺点
  1. 会有单点故障的问题(如果该服务器挂掉了,就无法请求)
  2. 随着业务扩展,代码越来越复杂,代码质量参差不齐,会让你每次提交代码 ,修改每一个小bug都是心惊胆战的。
  3. 部署慢(由于单体架构,功能复杂)代码量大了,部署就超级慢
  4. 扩展成本高(只能考虑从硬件上扩展)

3. 单体架构增加服务器

微服务(一)——单体架构 VS 微服务架构-左眼会陪右眼哭の博客
(假设每个服务器只能抗住200用户,怎么才能让两台服务器起到均衡分配的作用?)
采用Nginx负载均衡,使得每台服务器都能平均分压。

4. 负载均衡后会带来一个分布式session的问题

4.1 什么是分布式session的问题?
    网站是需要登陆的,登录的信息是保存在服务端,浏览器服务端请求是http请求,而http请求是短链接,无状态的,这意味着这次请求和下次请求是没有关系的,如果有session id的话,会将其保存在服务端,用来进行通讯。所以当使用分布式后,请求的服务器和响应的服务器可能不是同一个,这就会导致分布式的session不同步。
4.2 分布式session解决方案
微服务(一)——单体架构 VS 微服务架构-左眼会陪右眼哭の博客
方案一:Session Sticky(不适用于流量大应用)
    利用负载均衡的策略,根据ip进行hash,将一个ip的所有session数据都存在一个tomcat上。能解决分布式session的问题,但是会存在局部的单点故障问题(当一个服务器挂掉,就拿不到数据了)
方案二:Session Relication(不适用于流量大方案应用)
    该方案是一个session复制的方案,多个服务器的数据进行同步。能解决分布式session的问题和单点故障的问题,但有一个很大的弊端,非常的耗内存,耗宽带,每一个tomcat都会保存所有的session数据,当tomcat服务器多了,每更新一天数据都要相互同步通知,非常耗宽带。
方案三:Session Center
    需要增加额外的技术:Redis。该方案能解决方案一和方案二的问题,但是也有一个问题,需要增加Redis,Redis数据库也需要维护和高可用,对此要求特别高(全世界使用redis最多的公司是:新浪)。

5. 网站流量再增大后数据库解决措施

随着流量的继续增加,最暴力的措施就是直接增加服务器。
微服务(一)——单体架构 VS 微服务架构-左眼会陪右眼哭の博客
直接增加服务器可以解决应用程序的吞吐量和并发,但会遇到一个新的问题:数据库受得了吗?

解决方案:
* 读写分离
互联网网站的特性:读多写少
读写分离是指插入数据一般使用master主数据库,读数据一般使用slave从数据库。因此读写分离必须要有一个前提条件:主从同步。
mysql自带一个主从同步的机制:来同步binlog日志来实现主从同步的逻辑。
在这里插入图片描述

主从同步底层原理:
微服务(一)——单体架构 VS 微服务架构-左眼会陪右眼哭の博客
读写分离的两种解决方案:
微服务(一)——单体架构 VS 微服务架构-左眼会陪右眼哭の博客
proxy代理的方法(代理层):是指使用atlas代理实现方法增强(360开源的框架),根据不同情况,插入数据选择master数据库,查询数据选择slave数据库。判断是再proxy代理层进行的。
jdbc增强的方法(应用层):使用jar包拦截jdbc协议,再根据sql进行逻辑判断选择不同数据库。

两种方法对比:
proxy性能差一点,扩展性强,支持跨语言,大多数会用这种方案;jdbc增强性能好,但是具有局限性,不支持跨语言。

应用:如果在slave从数据库中修改数据,数据可能不会同步到master主数据库,但是如果使用主数据库代理后去查数据,查到的应该是被修改过的从数据库的数据,而不是未修改的主数据库数据,这就说明实现了读写分离。

主从同步的弊端(面试必考):当商品下单成功时,数据插入到了master数据库里,但是在同步binlog的过程中出现了故障,导致数据没有及时同步,就会出现问题。
解决方案:强制路由(注释的逻辑)
在执行语句前面加注解的方式

微服务(一)——单体架构 VS 微服务架构-左眼会陪右眼哭の博客
第一条语句走的是查询slave数据库,第二条语句强制路由,走的是master数据库。

  • 分库分表
    参考:https://database.51cto.com/art/201809/583857.htm
    分库分表的方式方法
    一般就是垂直切分和水平切分,这是一种结果集描述的切分方式,是物理空间上的切分。
    ①:单个库太大,这时我们要看是因为表多而导致数据多,还是因为单张表里面的数据多。 如果是因为表多而数据多,使用垂直切分,根据业务切分成不同的库。
    ②:如果是因为单张表的数据量太大,这时要用水平切分,即把表的数据按某种规则切分成多张表,甚至多个库上的多张表。 分库分表的顺序应该是先垂直分,后水平分。 因为垂直分更简单,更符合我们处理现实世界问题的方式。
    微服务(一)——单体架构 VS 微服务架构-左眼会陪右眼哭の博客
    垂直分库
    微服务(一)——单体架构 VS 微服务架构-左眼会陪右眼哭の博客
    水平分库
    在这里插入图片描述

微服务& 微服务架构

微服务理解

微服务的定义:http://blog.cuicc.com/blog/2015/07/22/microservices
微服务核心就是把传统的单机应用,根据业务将单机应用拆分为一个一个的服务,彻底的解耦,每一个服务都是提供特定的功能,一个服务只做一件事,类似进程,每个服务都能够单独部署,甚至可以拥有自己的数据库。这样的一个一个的小服务就是微服务,可以理解为是去中心化的一个逻辑。

①: 比如传统的单机电商应用, 商城里面有订单/支付/库存/物流/积分等模块(理解为servcie)
②:我们根据 业务模型来拆分,可以拆分为 订单服务,支付服务,库存服务,物流服务,积分服务
③若不拆分的时候,我的非核心业务积分模块 出现了重大bug 导致系统内存溢出,导致整个服务宕机.若拆分之后,只是说我的积分微服务不可用,我的整个系统核心功能还是能使用。
在这里插入图片描述

微服务的架构

  • 微服务架构是一个架构风格, 提倡
    ①:将一个单一应用程序开发为一组小型服务.
    ②:每个服务运行在自己的进程中
    ③:服务之间通过轻量级的通信机制(http rest api)
    ④:每个服务都能够独立的部署
    ⑤:每个服务甚至可以拥有自己的数据库
  • 微服务以及微服务架构的是二个完全不同的概念。
    微服务强调的是服务的大小和对外提供的单一功能,而微服务架构是指把 一个一个的微服务组合管理起来,对外提供一套完整的服务。
微服务的优缺点
  • 优点
    ①:每个服务足够小,足够内聚,代码更加容易理解,专注一个业务功能点(对比传统应用,可能改几行代码 需要了解整个系统)
    ②: 开发简单,一个服务只干一个事情。(假如你做支付服务,你只要了解支付相关代码就可以了)
    ③: 微服务能够被2-5个人的小团队开发,提高效率
    ④: 按需伸缩
    ⑤: 前后端分离, 作为java开发人员,我们只要关系后端接口的安全性以及性能,不要去关注页面的人机交互(H5工程师)根据前后端接口协议,根据入参,返回json的回参
    ⑥:一个服务可用拥有自己的数据库。也可以多个服务连接同一个数据库.
  • 缺点:
    ①:增加了运维人员的工作量,以前只要部署一个war包,现在可能需要部署成百上千个war包 (k8s+docker+jenkis )
    ②: 服务之间相互调用,增加通信成本
    ③:数据一致性问题(分布式事物问题)
    ④:系能监控等,问题定位等等

微服务的适用场景

A:合适
①:大型复杂的项目
②:快速迭代的项目
③:并发高的项目
B:不合适
①:业务稳定,就是修修bug ,改改数据
②:迭代周期长 发版频率 一二个月一次.

0 条回应
在线人数:1人 来访统计
隐藏