什么是系统架构设计?

定义：

一个软件随着功能越来越多，整个软件系统逐渐碎片化，如果不采取有效措施，软件系统就会越来越无序，最终无法维护和扩展。

所以说软件在一段时间的生长后，就需要及时干预，避免越来越无序，架构的本质就是对软件系统进行有序化重构，使软件系统不断进化。

扩展资料：

系统构架是对已确定的需求的技术实现构架、作好规划，运用成套、完整的工具，在规划的步骤下去完成任务。

抽象来说，它是计算机系统结构，或称计算机体系结构，是一个系统在其所处环境中最高层次的概念；它确定一台计算机硬件和软件之间的衔接。

具体地说计算机体系结构指的是计算机系统设计的观念与架构，描述计算机在实做的设计原则。

它确定一个计算机设计的部件功能 ，部件间接口 并且计算机体系结构着重于“负责了计算机架构的中心功能：计算”的中央处理器内部的运行动作与存储器的访问。

参考资料：

百度百科：系统构架

在架构设计：文件服务的设计与实现一文中，通过实现一个文件服务来梳理了一个架构设计的一般流程，并得到如下静态架构图

本文继续聊聊文件服务中的子模块：「存储模块」的设计，包括：

前面的架构没有对存储进行特别设计，直接使用了本地存储。考虑到后期文件数量可能会越来越多，本地存储可能无法支撑，且本地存储的安全性也没有保障。为了便于后期扩展，需要对「存储」部分进行设计。

存储的方式有很多，本地存储、NAS、分布式存储，为了能支持不同的存储方式，需要对「存储模块」进行抽象。考虑到「存储模块」涉及到IO，是一个相对底层的模块。「上传」这个核心模块不能依赖于具体的存储，所以这里也需要对其进行依赖反转。

见紫色部分，UploadService调用了FileInfoRepository来存储FileInfo，而FileInfoRepository是个接口，具体实现由存储模块中的实现类来实现。

我们先看本地存储。最简单的实现，就是直接使用IO将文件写到对应的目录下就可以了。但是，本地存储会有如下几个问题：

下面我们针对上面的问题，来一个个的解决。

首先，对于多租户来说，在我们的架构中，实际对应的是Group，我们按照Group的不同，来划分目录即可。即 不同的租户有不同的文件根目录 ，后期某个租户迁移时，直接迁移对应目录即可。这也稍微解决了单目录文件数量多的问题。

对于单目录下，随着文件数量的增加导致访问速度下降的问题，我们该如何解决呢？

如果你做过分布式系统，那么想一想， 我们是否可以把单目录看成是一个服务器，访问目录下的文件看成是一个个的请求呢 ？如果可以，那解决单目录下访问速度慢的问题是不是就变成了「如何解决单服务器下，负载过高」的问题了？那解决服务端负载过高的方法是否适用于解决目录访问速度下降的问题呢？

我们从下面几个方面来分析一下：

首先来看「解决服务端负载过高的方法」！答案很明显： 分流+负载均衡 ！

分布式服务的负载均衡有几种方式呢？

再来看「目录访问和服务器的区别」，虽然可以把目录看成服务器，但是两者还是有区别的：

也就是说，对于目录来说，我们不需要考虑创建成本。

那么针对服务器负载高的解决方案是否适合目录访问呢？或者哪种方式适合目录访问呢？我们一个个来分析：

可以看到，主要的问题就是创建目录的问题！如何保证在目录数量改变时，不需要调整程序呢？

实际上git已经给出了答案：

也就是说，根据sha1散列的前两位对文件进行归类。这样既解决了目录创建问题，也解决了文件分布问题。可能的问题是，「sha1散列2^80次，可能会发生一次碰撞」。这个问题对于一般文件系统来说，好像也没有担心的必要。

解决了「单目录文件过多，导致访问速度下降」的问题，我们来看下一个问题： 数据安全 。

文件数据是存放在电脑磁盘上的，如果硬盘损坏，可能导致文件的丢失。这实际还是一个「单点问题」！

「单点问题」的解决方案是什么呢？ 冗余 啊！

最简单的方案就是定时去备份数据，可以有如下几种方案：

我们继续一个个的讨论。

首先是 人工备份 ，这是最low的方案，当然也是最简单的，即有人定期去备份就行了。问题是时效性不高，例如一天备份一次，如果磁盘在备份前坏了，那就会丢失一天的数据。同时恢复比较耗时，需要人工处理。

第二个方案是 代码实现 ，即在上传文件时，程序就自动备份。以上面的架构为例，可以添加一个BackupListener，当上传完成后，通过事件，自动备份上传的文件。同时下载时需要判定文件是否完整，如果有问题则使用备份数据。此方案时效性得到了保障，但是将数据备份和业务放到了一起，且需要编码实现，增加了业务代码量。

第三个方案是 libfuse ，libfuse是用户态文件系统接口。下面是libfuse官方简介：

简单来说，就是可以用libfuse构建一个用户态文件系统。之前在老东家做了一个日志分析平台，日志的收集就使用了libfuse，大致架构如下：

业务系统写日志到挂载的用户态文件系统中，用户态文件系统自动转发到了后续的处理中间件：redis、消息队列、文件系统。

在这里也可以用类似的功能，即在文件上传后，用户态文件系统自动备份。此方案解耦了文件备案逻辑与业务逻辑。

最后一个方案是 RAID ，即廉价冗余磁盘阵列。RAID不但可备份文件，还支持并发读写，提高上传下载速率。

常用的RAID有：RAID0，RAID1，RAID01/RAID10，RAID5和RAID6等。我们来看看这几种RAID的特点，以及是否适用于我们的文件服务。你会发现从RAID0到RAID6，又是一个从单点到分布式的过程。

看下面的两张图应该能更好的理解：

无论是RAID10还是RAID01，对磁盘的使用效率都不高。那如何提高磁盘使用率呢？就有了RAID3。

对于本地存储来说，RAID是个相对实用的解决方案，既能提高数据安全、快速扩容，也提高了读写速率。但是无论扩展多少磁盘，容量还是相对有限，吞吐也相对有限，同时由于其还是单点，如果文件服务本身挂掉，就会导致单点故障。所以就有了分布式文件系统。

分布式文件系统下次单独讨论！

最后打个广告，帮朋友开的专栏《零基础Unity3D 游戏 开发》，适合没有基础、想从事 游戏 开发的小白！朋友从事 游戏 多年，开发了多款 游戏 ，收了30多个徒弟，技术杠杠的！

一个非常好的问题。云服务已经成为IT技术创新的核心基础设施，充分利用云服务带来的d性和分布式优势，赋能自动化运维。

关键词：DevOps，云原生

一，自动化部署

CI/CD持续化集成和自动化部署，以前经常使用Jenkins，配置Git代码提交时触发构建，然后通过脚本触发自动部署。

使用云服务后，以阿里云为例，利用丰富的DevOps运维工具，将代码托管、测试、部署等步骤更加高效的串联起来。

二，AutoScaling自动伸缩

集群化部署时，配置一定的触发条件，满足时将自动增加或者释放服务器资源。比如当CPU使用率达到85%或者内存占用率达到85%时，根据配置好的服务器和数量，自动触发。

三，云监控CloudMonitor

主流云服务商都将监控功能集成到了基础架构中，以阿里云为例，云监控提供了多种配置，多维度全方位监控。

比如配置CPU使用率到达85%时，自动触发动作，增加服务器实例，同时邮件通知运维人员。

四，Docker容器技术

Docker将应用以及依赖打包到一个可移植的镜像中，可以实现虚拟化，有助于快捷高效的交付应用。

搭建阿里云容器镜像服务+Git+Docker自动构建系统，结合资源编排服务，实现自动部署更新，不再需要单独部署维护Jenkins构建服务器。

五，云原生

云原生是指从开始设计应用时，就充分考虑并且利用云服务的特点，比如d性和分布式，可以简单的理解为：云原生=微服务+DevOps+持续交付+容器化。

在云原生应用系统里，运营、维护和监控，完全是自动化的。

单台服务器
这个是最简单的服务器部署方法，SharePoint 2010 所有的服务和SQL服务器都安装在一台服务器上。
两台服务器
在这种部署情景下，SharePoint 2010 所有的功能都单独装在一台服务器上，而把SQL 服务器独立出去。
三台服务器
当有三台服务器时就可以将SharePoint 2010服务器设计成高可靠性的解决方案，即采用NLB的架构的形式。
四台服务器
当有4台或以上的服务器时，就可以同时考虑性能和高可靠性。可以将Web前端服务器和查询服务器进行负载均衡，并与其他的应用服务分离部署。但是当只有4台服务器时，把其他的应用服务单独部署在一台服务器上并不是一个好的方法，因为这台服务器不具备高可靠性，当这台服务器崩溃时，整个应用服务就会垮掉。
服务器组
当服务器再网上增加时，可以考虑服务器组的概念。服务器组就是将SharePoint中类似逻辑概念的服务应用程序一起部署在同一组硬件上。这意味着随着每个层需求的增加，你可以为之添加额外的服务器进行支持。同时，这种方式还可以隔离不同服务对整体性能的影响，从而保证整体系统运行的性能。

用户使用通用的Web浏览器，通过接入网络(网站的接入则是互联网)连接到Web服务器上。用户发出请求，服务器根据请求的URL的地址连接，找到对应的网页文件，发送给用户，两者对话的“官方语言”是>