一个好的系统的自我修养

淡淡的烟草味﹌ 2023-06-17 12:57 16阅读 0赞

# 前言 #

一般一个系统大概分3个部分，前端  -  后端  -  数据库。

前端       可能是N台电脑，N个手机，所以压力最小

后端       很多个用户操作电脑端或者手机端请求    压力很大

数据库     又有1个或者多个后端程序来请求它，   所以它的压力是最大，资源也是最紧张的

所以我们设计的系统的准则是什么：尽量把一些计算，存储信息往前推。

大概意思就是，能在前端完成的尽量在前端完成，能在后端完成的尽量在后端程序完成

数据库最好就一个存储数据的功能，做数据持久化的操作，尽量什么计算，功能都不做。

# 前端 #

现在是大前端时代（大前端时代简单的说就是利用html5或者6甚至7，不但可以开发传统的网站，做炫酷的网页动态效果，更可以采用BS架构应用程序、开发手机端web应用、移动端Native应用程序、智能设备（比如可穿戴智能手表，可穿戴智能衣服）、以及各种游戏等。）前端现在已经从整个系统架构中分离出去，有了自己的服务器，有了自己的部署打包工具（nodejs，webpack）

所以前端现在分担的压力也越来越重，比如VUE来说，它有很多自己的组件，有自己的Session Storage,可以保存session信息，

比如用户登录信息等，有自己的router功能，可以根据后端返回跳到不同的页面。这些功能在JSP时代都是由后端来实现的。这样

前端就分担了后端的很多压力。

前端的代码又放在Nginx,Nginx是什么？Nginx 是异步框架的网页服务器，也可以用作反向代理、负载平衡器和 HTTP 缓存。

QPS能够达到百万级别的。

1，反向代理   就是把前端的请求服务，根据请求地址不同，分发到不同的后端服务。

2，负载平衡   nginx可以配置平衡规则，来将请求转发到不同的集群中的某台服务器，基本有 轮询，权重，根据请求IP转发等

3，HTTP 缓存   可以将我的一些http请求缓存在NGINX服务器，比如：我有一个排名请求，这个东西我觉得它的实时性要求并不高，但用户又喜欢一直刷新它，看它的排名。我们就可以在nginx这里设置一个缓存，将这个请求缓存在nginx本地，并且设置一个缓存时间为30秒，这样，当请求过来时，先判断本地有没有缓存，没有则向后端请求，存储nginx并返回数据，下次再有相同请求，nginx直接返回nginx缓存的时候。

# 后端 #

nginx之后，请求就开始到后端了，如果是单体应用的话，转发到单体应用。

但是现在很多用分布式，微服务架构了，这个架构是什么？

1，首先要有个服务管理注册服务（eureka,nacos,consule等），系统内所有的服务都会

注册到注册服务，包括:服务器的服务名，服务IP，端口，是否上线等信息

2，然后你还得有个统一的网关 (zuul,gateway)，网关统一接受所有系统对外的接口，

网关的主要功能是对请求进行拦截，认证，分流，限流，熔断等。

3，服务之间的通信，现在流行的2个服务间的通信：RPC(DUBBO)和HTTP(feign)，服务之间通信的

限流，降级，通信等处理。

至少满足上面3点，才是一个微服务架构。

4，服务的监控：可以监控到服务之间的调用链路情况，方便我们管理服务，知道哪些服务性能需要优化等（**skywalking等**）

上面我们说到nginx请求之后，服务就开始请求到统一的网关服务。网关会根据你的请求路径和

网关的路由配置信息，就知道你要跳转的服务名，再根据各个系统再注册服务器上注册信息，

请求到各个服务中去处理你的请求，并将结果返回。这就是微服务的一个大概的流程。

其实这些功能用单体应用可能会更快些，没有这么多服务，技术，维护，部署要求更严格。

这个问题我在前面也有讲过 [快速入口][Link 1] 这里就再说了

## 后端优化 ##

后端优化其实有很多是可以做的，大概分几个部分

1，服务的拆分，又分垂直拆分和水平拆分。

垂直拆分：就是将一个服务拆分成多个服务。可以根据业务，可以根据功能。

比如我如果是一个商城的服务，按业务可以拆分成 订单服务，库存服务等

按功能又可以分成支付服务，邮件服务，分表服务等

水平拆分：一个服务如果压力比较大，将这个服务做成负载集群，这样就可以分担压力。

2，分布式调度的优化。

之前有项目因为要生成报表，采用服务的定时任务定时生成推送。但是这样有个问题，

如果我做了集群，那么集群中的每个节点的定时任务是分开的，都会到点执行任务。不好管理。

可以引入一些分布式的调度管理，比如xxl-job

3，缓存的应用。

缓存的应用应该是对查询请求响应提升最明显的。一般分布式的缓存采用redis。

3.1  它数据存储快（QPS都是几万到十多万，一般的MYSQL数据库的QPS大概好的也只1000+）

所以很多查询的数据可以采用缓存技术，将数据存储到redis缓存中，查询的时候先通过缓存找，

找不到再去数据库查找。可以采用分布式缓存技术和[canal][]来实现数据库和redis的同步

3.2   它可数据持久化，可以通过redis的rdb和aof结合将数据存储，保证数据不丢失。

3.3   它方便扩展，   可以通过集群，哨兵，[cluster][]等方式来扩展

4，中间件的应用。

服务间的通信还可以通过中间件的调用。中间件也有很多  rabbitmq,rocketmq,kafka等

中间件的作用主要就是 解耦，异步，削峰，可以比较这些中间件来适应不同的业务场景。

之前有个博客讲rabbitmq的一些数据重复和丢失问题。[可以去看看][Link 2]。

5，数据库的优化。

5.1，数据查询的优化。MYSQL可以根据你的慢查询模式来优化，[快速入口][Link 3]，可以找到你系统中

哪些语句比较耗时，去分析它，然后去优化语句。

5.2，有些查询由于体积庞大，已经从语句上无法去优化它了，这样你就要考虑从数据库物理上去解决它了

5.2.1，考虑数据库表的设计是否合理，可以将大表拆分成多个小表，查询多的分在一个表

5.2.2，考虑使用分表，将一个表拆分成多个表，可以使用[分表分库技术][Link 4]

5.2.3，考虑数据表[主从技术][Link 5]，服务调用数据库时采用[读写分离][Link 6]，平担数据库压力

5.3  上面几点还是不行的话，取用分布式的数据库吧，如tidb

当然还有很多其他的方案和中间技术，这里只是列出了博主的一些工作中的优化，欢迎大家补充。

[Link 1]: https://blog.csdn.net/shrek11/article/details/101112117
[canal]: https://blog.csdn.net/shrek11/article/details/103044257
[cluster]: https://blog.csdn.net/shrek11/article/details/103187258
[Link 2]: https://blog.csdn.net/shrek11/article/details/102541643
[Link 3]: https://blog.csdn.net/shrek11/article/details/95985983
[Link 4]: https://blog.csdn.net/shrek11/article/details/102719054
[Link 5]: https://blog.csdn.net/shrek11/article/details/102684302
[Link 6]: https://blog.csdn.net/shrek11/article/details/102692817