一次对架构的探索
作为一个后端程序员，对各种服务之间的联通以及配置有所欠缺是不行的，在对各种服务调用进行学习了解之后有了这篇文章
首先架构分为硬件架构和软件架构，硬件架构就是服务器之间的调用逻辑，软件架构就是业务之间的调用逻辑
下面分别展示简单的硬件架构和软件架构的图：
硬件架构：
软件架构：
硬件架构之间的调用：
nginx会处理所有的用户请求连接，如果遇到不合法的url，nginx会直接把请求拒之门外，
同时nginx也充当着负载均衡的角色：
使用nginx自带的upstream模块，可以很方便的做到负载均衡
注意点：
upstream模块必须写在http模块中，否则会触发报错，当修改了配置文件之后可以使用nginx -t来进行检查，快速发现问题
同时upstream还支持权重配置，直接在server后面加上对应的参数即可，如果不配置则使用默认的轮询配置
支持三种自带配置：
轮询，权重，iphash
nginx也可以通过local模块配置不同的需求，文件服务，接口服务，可以通过配置不同的local来做到不同的策略
常用的就是在请求到nginx之后，对请求加上一些需要的头文件
或者是http的基本鉴权basicAuth服务，nginx也提供了相关的模块进行实现
以及限制ip，限制带宽，ssl配置等
用户通过url访问到nginx之后，nginx通过负载均衡分别把请求发送到不同的服务器里面
服务器在接收到请求之后执行一系列的查询最终将结果返回
软件架构之间的调用：
当nginx把请求发送到服务器之后，下面就是服务器的表演时间了：
首先请求会通过网关，如果不能匹配到相关的路由，则会被之间返回
当请求通过了网关，那么接下来就是中间件层
在中间件层，会对请求路由的头文件或者其他约定的方式进行鉴权，鉴权不通过也将被返回
鉴权通过之后，则来到了basic层，现在开始调用函数，在函数内对请求字段进行校验，
然后通过查询缓存，或者数据库之后得到了返回值进行返回，这个时候会再次经过中间件，
此时可以记录一些必要的信息，比如请求总耗时，请求得到的内容等
这样就完成了一次请求
软件架构的启动：
请求进入到服务内是自上而下执行的，
但是启动刚好相反，是自下而上的
首先被加载的应该是全局的配置文件，包括mysql数据库信息，redis数据信息，mq账号信息
然后是mysql和redis和mq的初始化
当初这些底层数据都加载完毕之后，就可以对缓存进行操作了，按照需要把数据查询处理放到缓存内
然后是中间件注册到路由，最后是启动服务
当项目出现异常时：
对于一些err异常，当作错误返回，但是不能返回内部错误，应该设置统一的提示，并提示联系管理员，
同时记录log，并设置统一的err格式方便查看，管理员应该定期查看log，记录错误，并通知开发进行跟进解决
当项目出现panic时：
此时应保证项目能继续运行下去，我们应该在中间件中加入recovery函数，首先对可用性做到保证，
但是对于无法恢复的panic则没有任何帮助，这个时候就需要邮件通知开发，进行排查和修复
同样的，在发生任何级别的panic时，都应发送通知邮件到开发的邮箱，并及时处理
当项目需要升级时：
我们假设项目全部运行在docker中，且没有使用容器编排技术
首先要做的就是把需要升级的程序运行起来，当运行起来之后，再次进行最后的流程测试
然后时修改nginx的配置文件，在负载均衡中修改新的程序的地址，然后通过nginx自带的优雅重启做到切换
最后停掉旧的程序，旧程序应该保存
如果使用了k8s：(不太了解，先不讲了)
使用k8s的特性可以方便的帮我们做到负载均衡和弹性扩/缩容，但是要提前考虑好容器的资源分配，避免扩容之后
出现无法有效解决问题的情况
jio的可以点个赞撒~
