周二，我们聊了架构出现的历史背景和推动因素。以史为鉴，对我们了解架构设计的目的很有帮助。谈到架构设计，相信每个技术人员都是耳熟能详，但如果深入探讨一下，“为何要做架构设计？”或者“架构设计目的是什么？”类似的问题，大部分人可能从来没有思考过，或者即使有思考，也没有太明确可信的答案。
架构设计的误区
关于架构设计的目的，常见的误区有：
- 因为架构很重要，所以要做架构设计
这是一句正确的废话，架构是很重要，但架构为何重要呢？
例如：不做架构设计系统就跑不起来么？
其实不然，很多朋友尤其是经历了创业公司的朋友可能会发现，公司的初始产品可能没有架构设计，大伙撸起袖子简单讨论一下就开始编码了，根本没有正规的架构设计过程，而且也许产品开发速度还更快，上线后运行也还不错。
例如：做了架构设计就能提升开发效率么？
也不尽然，实际上有时候最简单的设计开发效率反而是最高的，架构设计毕竟需要投入时间和人力，这部分投入如果用来尽早编码，项目也许会更快。
例如：设计良好的架构能促进业务发展么？
好像有一定的道理，例如设计高性能的架构能够让用户体验更好，但反过来想，我们照抄微信的架构，业务就能达到微信的量级么？肯定不可能，不要说达到微信的量级，达到微信的 1/10 做梦都要笑醒了。
- 不是每个系统都要做架构设计吗
这其实是知其然不知其所以然，系统确实要做架构设计，但还是不知道为何要做架构设计，反正大家都要做架构设计，所以做架构设计肯定没错。
这样的架构师或者设计师很容易走入生搬硬套业界其他公司已有架构的歧路，美其名曰“参考”“微改进”。一旦强行引入其他公司架构后，很可能会发现架构水土不服，或者运行起来很别扭等各种情况，最后往往不得不削足适履，或者不断重构，甚至无奈推倒重来。
- 公司流程要求系统开发过程中必须有架构设计
与此答案类似还有因为“架构师总要做点事情”，所以要做架构设计，其实都是舍本逐末。因为流程有规定，所以要做架构设计；因为架构师要做事，所以要做架构设计，这都是很表面地看问题，并没有真正理解为何要做架构设计，而且很多需求并不一定要进行架构设计。如果认为架构师一定要找点事做，流程一定要进行架构设计，就会出现事实上不需要架构设计但形式上却继续去做架构设计，不但浪费时间和人力，还会拖慢整体的开发进度。
- 为了高性能、高可用、可扩展，所以要做架构设计
能够给出这个答案，说明已经有了一定的架构经历或者基础，毕竟确实很多架构设计都是冲着高性能、高可用……等“高 XX”的目标去的。
但往往持有这类观点的架构师和设计师会给项目带来巨大的灾难，这绝不是危言耸听，而是很多实际发生的事情，为什么会这样呢？因为这类架构师或者设计师不管三七二十一，不管什么系统，也不管什么业务，上来就要求“高性能、高可用、高扩展”，结果就会出现架构设计复杂无比，项目落地遥遥无期，团队天天吵翻天……等各种让人抓狂的现象，费尽九牛二虎之力将系统整上线，却发现运行不够稳定，经常出问题，出了问题很难解决，加个功能要改 1 个月……等各种继续让人抓狂的事件。
架构设计的真正目的
那架构设计的真正目的究竟是什么？
从周二与你分享的架构设计的历史背景，可以看到，整个软件技术发展的历史，其实就是一部与“复杂度”斗争的历史，架构的出现也不例外。简而言之，架构也是为了应对软件系统复杂度而提出的一个解决方案，通过回顾架构产生的历史背景和原因，我们可以基本推导出答案：架构设计的主要目的是为了解决软件系统复杂度带来的问题。
这个结论虽然很简洁，但却是架构设计过程中需要时刻铭记在心的一条准则，为什么这样说呢？
首先，遵循这条准则能够让“新手”架构师心中有数，而不是一头雾水。
新手架构师开始做架构设计的时候，心情都很激动，希望大显身手，甚至恨不得一出手就设计出世界上最牛的 XX 架构，从此走上人生巅峰，但真的面对具体的需求时，往往都会陷入一头雾水的状态：
“这么多需求，从哪里开始下手进行架构设计呢？”。
“架构设计要考虑高性能、高可用、高扩展……这么多高 XX，全部设计完成估计要 1 个月，但老大只给了 1 周时间”。
“业界 A 公司的架构是 X，B 公司的方案是 Y，两个差别比较大，该参考哪一个呢？”。
以上类似问题，如果明确了“架构设计是为了解决软件复杂度”原则后，就很好回答。
- “这么多需求，从哪里开始下手进行架构设计呢？”
——通过熟悉和理解需求，识别系统复杂性所在的地方，然后针对这些复杂点进行架构设计。
- “架构设计要考虑高性能、高可用、高扩展……这么多高 XX，全部设计完成估计要 1 个月，但老大只给了 1 周时间”
——架构设计并不是要面面俱到，不需要每个架构都具备高性能、高可用、高扩展等特点，而是要识别出复杂点然后有针对性地解决问题。
- “业界 A 公司的架构是 X，B 公司的方案是 Y，两个差别比较大，该参考哪一个呢？”
——理解每个架构方案背后所需要解决的复杂点，然后才能对比自己的业务复杂点，参考复杂点相似的方案。
其次，遵循这条准则能够让“老鸟”架构师有的放矢，而不是贪大求全。
技术人员往往都希望自己能够做出最牛的东西，架构师也不例外，尤其是一些“老鸟”架构师，为了证明自己的技术牛，可能会陷入贪大求全的焦油坑而无法自拔。例如：
“我们的系统一定要做到每秒 TPS 10 万”。
“淘宝的架构是这么做的，我们也要这么做”。
“Docker 现在很流行，我们的架构应该将 Docker 应用进来”。
以上这些想法，如果拿“架构设计是为了解决软件复杂度”这个原则来衡量，就很容易判断。
- “我们的系统一定要做到每秒 TPS 10 万”
——如果系统的复杂度不是在性能这部分，TPS 做到 10 万并没有什么用。
- “淘宝的架构是这么做的，我们也要这么做”
——淘宝的架构是为了解决淘宝业务的复杂度而设计的，淘宝的业务复杂度并不就是我们的业务复杂度，绝大多数业务的用户量都不可能有淘宝那么大。
- “Docker 现在很流行，我们的架构应该将 Docker 应用进来”
——Docker 不是万能的，只是为了解决资源重用和动态分配而设计的，如果我们的系统复杂度根本不是在这方面，引入 Docker 没有什么意义。
简单的复杂度分析案例
我来分析一个简单的案例，一起来看看如何将“架构设计的真正目的是为了解决软件系统复杂度带来的问题”这个指导思想应用到实践中。
假设我们需要设计一个大学的学生管理系统，其基本功能包括登录、注册、成绩管理、课程管理等。当我们对这样一个系统进行架构设计的时候，首先应识别其复杂度到底体现在哪里。
性能：一个学校的学生大约 1 ~ 2 万人，学生管理系统的访问频率并不高，平均每天单个学生的访问次数平均不到 1 次，因此性能这部分并不复杂，存储用 MySQL 完全能够胜任，缓存都可以不用，Web 服务器用 Nginx 绰绰有余。
可扩展性：学生管理系统的功能比较稳定，可扩展的空间并不大，因此可扩展性也不复杂。
高可用：学生管理系统即使宕机 2 小时，对学生管理工作影响并不大，因此可以不做负载均衡，更不用考虑异地多活这类复杂的方案了。但是，如果学生的数据全部丢失，修复是非常麻烦的，只能靠人工逐条修复，这个很难接受，因此需要考虑存储高可靠，这里就有点复杂了。我们需要考虑多种异常情况：机器故障、机房故障，针对机器故障，我们需要设计 MySQL 同机房主备方案；针对机房故障，我们需要设计 MySQL 跨机房同步方案。
安全性：学生管理系统存储的信息有一定的隐私性，例如学生的家庭情况，但并不是和金融相关的，也不包含强隐私（例如玉照、情感）的信息，因此安全性方面只要做 3 个事情就基本满足要求了：Nginx 提供 ACL 控制、用户账号密码管理、数据库访问权限控制。
成本：由于系统很简单，基本上几台服务器就能够搞定，对于一所大学来说完全不是问题，可以无需太多关注。
还有其他方面，如果有兴趣，你可以自行尝试去分析。通过我上面的分析，可以看到这个方案的主要复杂性体现在存储可靠性上，需要保证异常的时候，不要丢失所有数据即可（丢失几个或者几十个学生的信息问题不大），对应的架构如下：
学生管理系统虽然简单，但麻雀虽小五脏俱全，基本上能涵盖软件系统复杂度分析的各个方面，而且绝大部分技术人员都曾经自己设计或者接触过类似的系统，如果将这个案例和自己的经验对比，相信会有更多的收获。
小结
今天我为你分析了架构设计的误区，结合周二讲的架构设计的历史背景，给出架构设计的主要目的是为了解决软件系统复杂度带来的问题，并分析了一个简单复杂度的案例，希望对你有所帮助。
这就是今天的全部内容，留一道思考题给你吧。请按照“架构设计的主要目的是为了解决软件复杂度带来的问题”这个指导思想来分析一下你目前的业务系统架构，看看是否和你当时分析的结果一样？
欢迎你把答案写到留言区，和我一起讨论。相信经过深度思考的回答，也会让你对知识的理解更加深刻。（编辑乱入：精彩的留言有机会获得丰厚福利哦！）
最后给你推荐一个课程，极客时间新上线了《Java 核心技术 36 讲》，由 Oracle 首席工程师杨晓峰老师给你精讲大厂 Java 面试题，帮你构建 Java 知识体系，你可以点击下方图片进入课程。
版权归极客邦科技所有，未经许可不得转载
精选留言
需求驱动架构。在分析设计阶段，需要考虑一定的人力与时间去"跳出代码，总揽全局"，为业务和IT技术之间搭建一座"桥梁"。
架构设计处于软件研制的前期，一方面，越是前期，如有问题，就能够越早发现，修改的代价也就越低；另外一方面，也意味着，软件实施后期若有架构上的修改，也需要付出更多的代价。
今日得到:
1 架构是为了应对软件系统复杂度而提出的一个解决方案。
2 架构即(重要)决策
3 需求驱动架构，架起分析与设计实现的桥梁
4 架构与开发成本的关系
2. 一个简单的例子能说明相关问题也很赞，就是这样，大家有时不需要大而全的大公司大例子，反手一个赞，加油，运华兄
业务架构和业务量级都是从每个具体项目的实际应用场景中提炼出来的。
业务架构是对业务需求的提炼和抽象，开发软件必须要满足业务需求，否则就是空中楼阁。软件系统业务上的复杂度问题，可以从业务架构的角度切分工作交界面来解决。设计软件架构，首先是要保证能和业务架构对的上，这也是从业务逻辑转向代码逻辑的过程，所以软件架构的设计为开发指明了方向。另外架构设计也为接下来的开发工作分工奠定了基础。
业务量级表现在存储能力、吞吐能力和容错能力等，主要是软件运维期业务的复杂度。做软件架构设计，是要保证软件有能力托起它在业务量级上的要求的，如果软件到运行使用期废了，前面所有的工作都付诸东流了。不同的业务量级，对应的软件的架构复杂度是不同的，所以对于不同的项目，业务量级不同，架构设计也不同。
做业务架构必须与其面向的实际应用场景相匹配，由于每个产品或项目的业务场景均有所不同，所以每次做新的软件开发前，必须先设计软件架构，试图不经分析直接套用先前的架构方案，十有八九会让当前的系统在某个点上报出大问题导致推翻重来，更不要说直接拿别人的现成架构方案了。
所以每个软件在开发前，都要结合自己的应用场景设计适合自身的软件架构，现成的架构方案只能借鉴，不能直接套用。
另外，由于业务架构和业务量级也会不断调整或长大，软件架构也不是一劳永逸的，会随业务不断调整。
1.距离选择。如果太远可能就漏出来了
2.成本选择。如果拉屎太贵也不合适
3.性能选择。好的厕所可以拉的心情舒畅
1.方便内部非开发人员做数据存储
2.提供对象存储的图形化界面
3.监控整个存储集群的存储相关的指标，例如存储量，下行流量、api调用等等
这几个需求也算是我结合公司的现有业务状况，以及对象存储的特性，自己总结的。
系统上线以后，我预计的使用情况如下:
1.大的天使客户都是一些职能的业务部门，由存储集群提供底层的存储接口，通过中控台进行监控，图形化操作
2.其他零散人员，可存储一些工作上的数据
目前我只是做了个demo出来，整体架构:nginx做前端的负载，springboot提供服务，mysql存储元数据，redis做消息队列，以及缓存，数据通过接口传到存储集群
这个架构也没做太多考虑，就像老师您说的情况一样，只不过公司其他的系统也差不多都这样。
对象存储中控台的业务复杂度我思考有以下几个:
1.提供高可用，高性能的上传下载功能
2.提供bucket 以及对象的查询功能
3.提供低延迟的监控统计功能
4.并发访问量个人感觉都集中在存储集群的接口调用，中控台这边并不高，但是一定要做到系统的高可用，保证内部职工正常的工作使用，同时mysql也要做到主备和异地多活，以及redis的主备
老师这样的分析可以么，针对这样的业务，现有的架构有问题么
架构设计在发展的不同阶段面临不同的问题，例如我们公司刚开始就做了业务拆分，后端是多个服务，前端一个站点，并且提供了一个服务互相调用的公共代理，现在主站越来越庞大，涵盖的业务越来越多，所以要做业务拆分，公共代理所包含的服务也越来越多，也要进行拆分。另外一个业务要调用多个服务，如何去监控调用链的完整性，这也需要解决。
所以架构本身在不同阶段集中解决几个最主要的问题，之后随着业务，技术，问题的不断变化，架构的重点也在不断调整。
现有业务复杂度分析：
性能： 提供外部接口，对性能有一定的要求，对对存储也有一定要求，但访问量每天不高，1万~2万，mysql+缓存，还是有必要的，量不高，但要快
可扩展性：因为需要经常对接其他支付接口，所以这里的可扩展性有一定要求
高可用：这是重点，因为是提供给商场使用的支付接口，哪怕一分钟宕机都是不行的，针对高可用方案，我现在只能想到，在不同机器上部署多套服务，然后用nginx做负载。不过晚上没有交易，可以停机的。存储数据都是订单，这个很重要，因为每天需要查账，不过已经使用了阿里云的rds主备方案，这里也不用担心
安全性：现在接口都是用sign验签，而秘钥都是独立的，所以这里也没有问题了
综合来说，我们对高可用，稳定性是要求最多的，这是这里的复杂度
这是个好问题，值得每个架构师和想成为架构师的技术人经常思考。
为了解决软件复杂性，是经典答案；
个人认为架构设计的目的有:
制定群解决业务问题复杂性的解决方案规范，包括核心业务流、扩展点位置、流程重组规范、服务编排方 法、等等，简而言之规范是架构的灵魂，方 法 '论（比如DDD）是架构的指导意见，统一技术认知和屏蔽横向业务影响是架构核心价值。
拙见，请大家指正
不同的市场时机，不同的团队素质，也会衍生出不同的架构设计，没有对错，只有合不合适。
背景:我工作3年多，最近在学习uml，但是感觉程序设计帮助并不大。程序设计和编程还是靠经验和加班加出来的。
所以问题是，方法论这个东西在程序设计方面真的作用大吗？编程是不是还就是靠经验和加班？
不知道版主哥对方法论怎么看的，并且你用uml吗？
补充，uml我才用了3个月，只用它开发了3个功能，所以也可能是我资历太浅，没掌握要领和精髓。
谈谈我学到的
所谓的架构，就是在性能，可靠性，扩展性，安全，成本，之间做出权衡
根据自己产品的需求，在以上几点中选择最关键几个，然后放弃相对不重要的几个
比如创业公司为了成本就只能舍弃其他几个
而银行为了安全就可能需要放弃一些性能
秒杀系统为了性能就要在其他几个中做取舍
不知道我理解的对不对😅😅
2、忌完美主义
3、......
在做架构设计的时候应从需求入手，循序渐进，逐步细化。在做架构的过程中要让相关方理解系统设计，可以使用不同的视图工具。比如案例中的物理架构，还可以有逻辑架构和用例图。这样可以让开发人员，客户，管理人员，运维人员，都能很好理解系统设计，方便沟通。
1.识别和解决项目中主要的技术问题，保证项目能够顺利实行
2.保证的可以预见的未来不会存在无法处理的技术问题
架构设计的任务
1.发现主要的设计点
性能、搞可用、可扩展性、安全、质量、系统目标等
2.发现主要的技术问题：团队不熟悉的技术、解决方案
3.围绕主要设计点，提供对应的解决方案和支持
技术上的方案
管理、流程上的方案
其实之前，我在设计产品的过程中并没有考虑复杂性，而是一未模仿。也只考虑了计算高可用和系统安全性，并没有考虑存储高可用，系统安全性方面后台和前台设计技术手段一样，并没有区别对待。
2、分析问题的方法：分治
3、软件架构目的：降低分析软件领域发展同时带来的结构问题的难度
若果没有架构设计，等到开发中期，或者上线之后才发现复杂性带来的问题，如性能，安全等问题。那么就需要重构整个系统了，可以说非常痛苦。
所以说为什么需要有架构设计: 因为架构设计可以提前解决系统复杂性所带来的问题
而提前解决这些问题，避免这些问题在后期出现正是架构设计的目的所在
1. 架构设计不能过度设计，高大全的架构不能要。
2. 软件架构是用来解决“软件复杂度”的，脱离了业务需求去做架构设计往往会失败。
3. 架构师对业务需求的洞察能力非常重要，不能仅仅从技术角度来看待项目。
1. 架构设计不能过度设计，高大全的架构不能要。
2. 软件架构是用来解决“软件复杂度”的，脱离了业务需求去做架构设计往往会失败。
3. 架构师对业务需求的洞察能力非常重要，不能仅仅从技术角度来看待项目。
明确需求→分析复杂度→做出决策
嗯，感谢留言区第一的朋友，有启发。
“架构设计的主要目的是为了解决软件使用过程中因对象、目标、流程、环境复杂度带来的问题”
会不会更容易去理解架构设计的目的和本质，以及架构设计的目的和意义？
要知其然，也要知其所以然，诱惑与选择太多，这样把握住原则，才不至于迷失
关于这个云平台架构，结合您的分享，我的一些思考如下，不知是否到点
1 私有云平台承载的的应用主要为功能测试，因此数据可靠性和可用性要求 均不是特别高。 不需要考虑异灾备等复杂场景
2 云主机申请并发相对比较多， 消息队列集群要求较高
3 测试主机对流量要求较高，不能依赖于原生的open vswitch， 需要引进三方sdn设备
在实际的工作中，最忌讳的是一口想吃成大胖子
我理解的架构师更多的是学会思考与沟通，在成本中进行决策，任何技术脱离了业务场景都是没有意义的，就像纸上谈兵一样，所以架构师是产品与技术的桥梁，不会为了几辆车建高速公路，也不会只给几万辆车搭独木桥
一、对于“软件设计的主要目的是为了解决软件系统复杂度带来的问题”的理解：第一步，架构设计需根据需求确定系统各点的复杂度；第二步，根据复杂度的高低排列优先级，依次进行架构设计，不求面面俱到，但必须解决核心问题。
二、问题：
关于如何分析软件系统的复杂度，是否有可以参考和学习的方法论？能否深入介绍一下？
复杂度分为业务复杂度和技术复杂度。业务复杂度分离可以通过领域驱动等等去解决，而技术复杂度可以从高性能、高可用和数据一致性三个维度去分析。
比如我目前在弄的是公司的后台，框架是以前就弄好了的，我只是维护。用户除了公司内部人员就只有公司的一些客户，数据来源是日志以及一些线上的服务器，线上大概有几千台服务器，然后主要是有几台充值服。
用的是mysql，客户主要关心线上服的注册登入和充值情况，而起要求查询必须快点响应，但是充值数据有几千页，而且同时要获取登入注册相关信息，这些信息的数据库也每个表也有几百页，如果响应慢了，客户会重新刷新页面，再次点击，会造成线程不足挂掉，所以上司把这些数据存到了缓存里，就能实现快速查出结果。
由于充值数据数量大，所以在起服是不能一次性把它加载完，就需要将近一个小时，注册和创角也是一样的情况，所以就不能经常关闭维护。
每个客户只能查询与自己平台相关的数据。
这个项目的web容器是tomcat，数据库是
mysql，数据源用定时器从其它服务器获取以及解析日志，感觉没啥东西了。
那我这个项目的复杂点是不是就是性能和可用还有安全性三方面？架构有没有就不清楚了，如果有的话，感觉就是个星型拓扑图
隐私性没得说肯定需要，而且能开放用户配置。
容灾？的话，互联的多地存储，增一台，数据同步，宕一台，数据能从附近最近机器访问。
能对产生数据自动分类，目的是永久数据放redis，临时数据是产生用完即扔，这方面用户也可配置，提供数据查询下载..
多少人在线，自动开启多少服务器，多少带宽
...我想这种应用主要是hold住互联网web应用，符合人用网规律和机器利用规律
1.不贴近用户需求，70%以上的功能是用户平时不会用的，或根本不需要的
2.人为增加项目复杂度，流程设计繁琐，为所谓的可扩展设置很多预留功能，实际用户新增需求是这些预留功能根本无法满足，反倒是因为本身设计太复杂，随便一个小的改动可能产生不可预估故障。
3.系统使用太复杂，有的系统设置连开发人员都弄不清楚怎么用过段时间就忘记，更不用说普通用户。
4.服务器资源浪费，平均内存和cpu利用率不到30%
其他不一而足，但无力改变
架构是慢慢演进的，前期业务量小集中式能够完全满足，等业务量稍大了就要想着服务拆分，业务量再大点就得想着动态扩容，保证数据一致性等...
不过任何时候在设计架构时都要考虑扩展性，否则推倒重来就会很痛苦
我们公司的系统主要是采集数据的业务，由一个单体的控制服务端包括页面呈现端，和采集机集群多个节点组成。
主要业务是采集各种各样的数据。流程是服务端配置和调度控制，分派任务到采集端，采集端采集完数据
性能：对采集时间要求不是特别高，不同的采集项，要求的采集的时间不同。配置采集一天一次，一次大概采集1W台设备，预计2小时完成。
拨测数据5分钟一次，一次也采集大概1W台设备，5分钟内必须完成。并发任务多的时候可能2W-3W个任务同时下发。为了提高性能，程序内部的
配置信息（设备信息，采集指标信息，调度信息）采用了缓存，并通过采集机集群和轮询分发，并发去执行任务。并把数据流和控制流分开，采集控制信息通过
服务端和采集机的长连接传递，采集数据通过activityMQ上报给服务端入库。
可扩展：扩展性是我们系统的关键问题，因为是采集业务。需要采集的内容随业务变化，采集的方式也各不相同。现有架构处理这个问题，
是通过在采集机上实现不同的采集能力，并且将需要采集的内容封装成独立的任务，单台采集机机集成所有的采集能力，分派到不同的任务，就执行不同的
采集方式。其余的配置和调度，轮训下发，数据上报，采集数据结构采用的统一的规范，实现不同的采集，从配置->调度->到下发->采集->入库的动作都是一样的。
可靠性:配置的设备信息，指标数据不可丢失，结果数据按数据不同，最短不需要保留，最长保留3个月。用的oracle数据库，仅需要做主备或者定期备份。
由于告警数据需要采集，程序宕机接受时间在30分钟内，可以使用看门狗进行进程监控。
现在的问题：
1.控制服务端为了提高效率，配置信息使用了缓存，做双机热备的时候，备机的缓存与主机的不一致问题。
考虑是否将缓存单独提取成一个服务。
2.原先的设计是不同的采集项，都封装成不同的任务，相互独立，实现采集机的集群使用
比如采集A,B,C三个指标，就生成A,B,C三个任务，不论发给哪台采集机，都会去执行采集。
随着业务更加复杂，有些采集任务互相之间存在复杂的逻辑，比如采集C，一定要A采集完之后，
并且A的采集结果是X的时候，采集B，B的结果为空的时候采集C。
现在手头上这个项目就是属于第二种问题，需求迭代也快，动一发而牵全身，不可能一次调整整体架构，只能随着迭代每次重构一小个模块。实践越多，越对于“与复杂度做斗争”有感触。
着眼整个项目实现过程，觉得编码其实重点不是编码，而是思考的过程，如何分配资源，如何做取舍，代码也只是反应了思考的结果和文法功底
学校情况就是2万人左右，教务系统每当抢课必定宕机。
记得有次面试，在这个项目上写了从高并发高性能方面考虑，然而问起什么都不会说😊。
架构设计:
登录方面:基于学校教务系统的代理登录，哈哈，我在想，可以做个缓存系统来避免高峰期的页面缓慢问题。
学生信息方面:就如作者所说，做好储存系统的方案，主机房有主、从备份，还有备机房。
功能方面比较少。
哈哈哈哈