微服务（一）——单体架构 VS 微服务架构

不愿意做鱼的小鲸鱼

发布于 2022-09-26 18:23:36

2.1K00

代码可运行

文章被收录于专栏：web全栈web全栈

运行总次数：0

代码可运行

单体架构 VS 微服务架构

单体架构

1. 什么是单体架构

一个工程对应一个归档包(war)，这个war包包含了该工程的所有功能。我们成为这种应用为单体应用，也就是我们常说的单体架构。具体描述: 就是在我们的一个war包种，聚集了各种功能以及资源，比如JSP,JS,CSS等。

2. 单体架构优缺点总结

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

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

3. 单体架构增加服务器

（假设每个服务器只能抗住200用户，怎么才能让两台服务器起到均衡分配的作用？） 采用Nginx负载均衡，使得每台服务器都能平均分压。

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

4.1 什么是分布式session的问题？网站是需要登陆的，登录的信息是保存在服务端，浏览器服务端请求是http请求，而http请求是短链接，无状态的，这意味着这次请求和下次请求是没有关系的，如果有session id的话，会将其保存在服务端，用来进行通讯。所以当使用分布式后，请求的服务器和响应的服务器可能不是同一个，这就会导致分布式的session不同步。 4.2 分布式session解决方案

方案一：Session Sticky（不适用于流量大应用）利用负载均衡的策略，根据ip进行hash，将一个ip的所有session数据都存在一个tomcat上。能解决分布式session的问题，但是会存在局部的单点故障问题（当一个服务器挂掉，就拿不到数据了）方案二：Session Relication（不适用于流量大方案应用）该方案是一个session复制的方案，多个服务器的数据进行同步。能解决分布式session的问题和单点故障的问题，但有一个很大的弊端，非常的耗内存，耗宽带，每一个tomcat都会保存所有的session数据，当tomcat服务器多了，每更新一天数据都要相互同步通知，非常耗宽带。方案三：Session Center 需要增加额外的技术：Redis。该方案能解决方案一和方案二的问题，但是也有一个问题，需要增加Redis，Redis数据库也需要维护和高可用，对此要求特别高（全世界使用redis最多的公司是：新浪）。

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

随着流量的继续增加，最暴力的措施就是直接增加服务器。

直接增加服务器可以解决应用程序的吞吐量和并发，但会遇到一个新的问题：数据库受得了吗？

解决方案：

读写分离 互联网网站的特性：读多写少 读写分离是指插入数据一般使用master主数据库，读数据一般使用slave从数据库。因此读写分离必须要有一个前提条件：主从同步。 mysql自带一个主从同步的机制：来同步binlog日志来实现主从同步的逻辑。

主从同步底层原理：

读写分离的两种解决方案：

proxy代理的方法（代理层）：是指使用atlas代理实现方法增强(360开源的框架)，根据不同情况，插入数据选择master数据库，查询数据选择slave数据库。判断是再proxy代理层进行的。 jdbc增强的方法（应用层）：使用jar包拦截jdbc协议，再根据sql进行逻辑判断选择不同数据库。

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

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

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

第一条语句走的是查询slave数据库，第二条语句强制路由，走的是master数据库。

分库分表参考：https://database.51cto.com/art/201809/583857.htm 分库分表的方式方法 一般就是垂直切分和水平切分，这是一种结果集描述的切分方式，是物理空间上的切分。 ①:单个库太大，这时我们要看是因为表多而导致数据多，还是因为单张表里面的数据多。如果是因为表多而数据多，使用垂直切分，根据业务切分成不同的库。 ②:如果是因为单张表的数据量太大，这时要用水平切分，即把表的数据按某种规则切分成多张表，甚至多个库上的多张表。分库分表的顺序应该是先垂直分，后水平分。因为垂直分更简单，更符合我们处理现实世界问题的方式。

垂直分库

水平分库

微服务& 微服务架构

微服务理解

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

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

微服务的架构

微服务架构是一个架构风格, 提倡 ①:将一个单一应用程序开发为一组小型服务. ②:每个服务运行在自己的进程中 ③:服务之间通过轻量级的通信机制(http rest api) ④:每个服务都能够独立的部署 ⑤:每个服务甚至可以拥有自己的数据库
微服务以及微服务架构的是二个完全不同的概念。微服务强调的是服务的大小和对外提供的单一功能，而微服务架构是指把一个一个的微服务组合管理起来，对外提供一套完整的服务。

微服务的优缺点

优点 ①：每个服务足够小,足够内聚，代码更加容易理解,专注一个业务功能点(对比传统应用，可能改几行代码需要了解整个系统) ②: 开发简单，一个服务只干一个事情。（假如你做支付服务，你只要了解支付相关代码就可以了） ③: 微服务能够被2-5个人的小团队开发，提高效率 ④: 按需伸缩 ⑤: 前后端分离, 作为java开发人员，我们只要关系后端接口的安全性以及性能，不要去关注页面的人机交互(H5工程师)根据前后端接口协议，根据入参，返回json的回参 ⑥:一个服务可用拥有自己的数据库。也可以多个服务连接同一个数据库.
缺点: ①:增加了运维人员的工作量，以前只要部署一个war包，现在可能需要部署成百上千个war包 (k8s+docker+jenkis ) ②: 服务之间相互调用，增加通信成本 ③:数据一致性问题(分布式事物问题) ④:系能监控等,问题定位等等