可用的系统并且这种系统也需要随着现实情况的变化而调整乃至于重构其自身。所以整个系统不能看成是绝对稳定的系统的架构会随着各种各样内外部条件的变化而不断演进其总有着发生变化的趋势。由此可见系统的结构不仅仅源自于人为的刻意设计而且还要受到各种因素的影响。这其中包括业务需求、软硬件性能、人员专业能力等技术性因素还包括人事、经济、政策等非技术性因素。简而言之就是系统架构并非是一开始就人为设计好的而是各种因素综合作用的结果并且其还会随着现实情况的变化而不断演进。积极实践逐步认识要想获得对事物的认识就必须先进行实践因为知识只能从实践中产生。当遇到一个难以解决的问题时自己应当先去调查这个问题的现状与历史而不是仅仅局限于现有的知识范围。并且调查不能只停留于书本之上还应在现实中进行实际的调查。当问题的各方面都调查清楚了的时候解决问题的思路也就有了。构建系统也是如此当自己完全不知道该如何构建合适的系统时就应该先去了解和学习他人已经构建好的系统。然后自己尝试着构建一个与现有系统相似的系统。自己最开始构建的系统大概率会有各种各样的问题有时还会崩溃甚至于某些功能都未能实现。但这只是整个系统构建过程的其中一个环节自己每重复一次这个过程就更多一分对系统的理解系统也因此变得更加完善。一直重复此过程直到系统已经初具规模自己对系统也有了足够认识的时候便可以开始着手构建符合自身需求的系统了。先通过实践来进行认识然后再通过实践来验证和发展这一认识而后又根据这一经过验证和发展的认识来指导进一步的实践。每经过一个实践与认识的循环这两者就更进一步的得到了发展。流水不腐户枢不蠹由于物质现实是变化运动的所以不能去预设系统的每个部分都是可靠的、静止的而是要在每个部件都有可能出现问题的前提下去设计系统。即使某些部件使用了及其不稳定的代码有严重的内存泄漏问题每隔几分钟就会崩溃一次但在整体系统设计得当、关键部件高可用、有自动化错误熔断和重建机制的依托下在外部看来系统整体仍然呈现出健壮和稳定的服务能力。这也是控制论的重要方法之一对于内部结构不断变化且不可预知的黑箱系统根据其输出端的实际输出与理论值的差别而不停地调整输入端的输入使得其能在动态平衡中保持正常运行。亦即通过负反馈循环让不稳定的系统时时刻刻调整其自身的状态从而在运动中达到相对平衡。自主可控降本增效自主可控的优点主要有两个抗风险和低成本。之所以自主可控能抗风险一是因为系统的关键部分与外部隔离在外部发生故障时可通过更换第三方备选方案来减少其对内部系统产生的影响使得系统能更快地恢复运行。二是因为当系统自主可控时他人无法从技术上威胁自己的核心利益使得自己在与他人博弈时能获得一定的力量优势从而消除某些可能会发生在外部的人为风险。至于低成本也是得益于此使他人在与自己博弈时没有决定性的优势。由于自己的核心部件自主可控不依赖绑定某一厂商有多种可替代方案。所以可在购买时选择更低价的产品在议价时获得更大的谈判空间。在许多时候产品的定价取决于交易双方的力量对比。当自身购买量足够多且能随时选择其他替代方案时产品的价格往往会变得极其低廉。伸缩自如扩展随意为了适应时刻都有可能进行调整的系统架构所以就要求系统中的部件也应是可变的此种可变不仅表现为单个部件可支配资源的升降还表现为多个相同部件数量的增减。于是在这种需求之下人们将具体的、孤立的、有差异的单个资源抽象为逻辑上的、统一调度的资源池。这使得人们能更加便捷的调整不同部件间的资源分配。在面对系统架构变化时除了要考虑物理配置与部件数量等资源上的增减还应考虑与之配套的功能上的增减。如果系统的功能复杂但其所拥有的资源有限此时系统会变得不稳定、抗风险能力差任何局部的突发事件都可能威胁整体的系统安全。反之如果系统的功能简单但其拥有的资源却又过剩此时就会造成资源浪费、成本上升。总的来说就是系统具有的功能要适应其所拥有的资源。当然这只是单纯的基于技术性的考量之下所得出的结论。不过如果将此处的资源理解为影响系统的一切因素的话以上结论依然成立。物尽其用按需选择应根据实际需求来选择系统的部件。对于超过了设计使用年限的部件如果其在实测时各方面的性能依然表现良好能满足实际需求那么就可以继续使用。类似的对于系统中性能要求较高的部分也应当使用性能较高的部件对于需要稳定运行的部分则应使用中规中矩最不容易出问题的部件。总而言之就是按需选择部件。这里所说的“需”不仅仅只是内部的、技术性的需求还有外部的、非技术性的需求。比如当需要迅速抢占市场快速推出产品时就应尽量简化架构并选择易于快速上线的部件。此时对于系统中存在的各种缺陷可以选择性的进行临时处理或者直接忽略。又比如当业务的总体利润远远高于其成本时则应当选择在各方面都具有较高品质的部件。分辨主次逐个解决在进行系统搭建的过程中会遇见各种各样的问题这里列举一些搭建计算机系统时可能会遇到的问题例如硬件不兼容、内存条不识别、硬盘坏道、BIOS设置错误导致黑屏、设备温度或功耗过高降频等硬件问题。以及驱动不识别硬件、软件源未加速、环境依赖安装失败、程序异常卡死崩溃、网络环境配置错误等软件问题。面对这种种问题首先要做的是分清主要问题和次要问题先解决主要问题以实现在最小范围内的正确可用然后再着手解决其他的问题。当主要问题在一定程度上得到了解决的时候主要问题便不再是主要的问题而是成为了次要的问题取而代之的是其他次要问题中最主要的方面这一过程就是主次矛盾相互转化的过程。在软件开发行业也有一个与之相符的经验总结“先让它能用再让它正确最后让它快速。”