架构师第八周学习总结

本周主要围绕性能优化讲了服务器、网络等相关话题。

一提到优化就是一个大工程，因为它包含的面非常广，涉及整个系统所有的方方面面。

1、硬件和操作系统

硬件需要和操作系统一起配合才能发挥作用。硬件的优化主要包括对：CPU、内存、磁盘和文件IO、网络的相关指标进行监控，对出现的异常表征，需要结合具体的业务场景去分析，并根据分析结果去验证，然后再是处理和优化。

某一硬件的指标不是孤立存在的，可能会引起连锁反应，某一个硬件指标的异常，常常会伴随着其他硬件指标的异常。因此，在排查此种问题时需要结合多种监控指标进行分析，切不可断章取义，盲目操作



2、应用/中间件

也就是相关的应用程序/组件以及相互之间的性能，单一的应用/组件可能是很好优化的，一旦将多个应用/组件纳入到系统的架构体系中来，那就不是1+1的关联了，相互之间的关联性会呈指数级的增长，出现问题的机率也是成倍增长，排除问题的阻碍也会非常困难。

对待应用/组件的采用要慎重，整体架构要简单适用，用最简单的架构解决当前最迫切的需求，而不要去追求大而全，这样只会越陷越深。

架构的造型-简单的，就是好用的，完美！



3、数据存储

数据，对一个现在的企业来说就是其核心，数据的保存及数据安全也是企业要解决的头等大事。

现在的数据库分成了两大阵营：以关系型数据库为代表的sql阵营和以非关系型数据库为代表的nosql阵营

不管是关系型数据库还是非关系型数据库，都是有其应用场景的，关系型数据库注重ACID，保证数据的存储安全（数据不丢失，事务一致性）。非关系型数据库注重大海捞针（处理海量数据的查询、存储需求）。

在这块的选型上要结合企业的具体应用场景来选择，而不是按冷热程序来选型。企业不是技术的实验场，尤其是数据块这块，你的一个决策很可能就决定了一个企业的命运。

数据库选型后，就要决定采用什么架构，数据冗余是首要考虑的问题，保证在任何情况下都能保证有一份数据是可用的。然后要考虑数据的高可用，即数据库服务器发生故障后，还有备用节点顶替故障节点对外提供数据服务，不至于因此造成前端应用的不可用。

对于分布式数据库，需要保持谨慎，能不用就尽量不要用，实在想用的时候，再想想，想想，多想想！能业务层面解决的就不要让数据库来解决，不要让数据库承载太多，毕竟它就是一应用软件，他的主要作用就是存取数据。



架构师要学会化整为零，再分而治之，再适度融合。总结一个字：度。现在技术都是公开的，通过各种渠道都可以获取到，但“度”是从任何地方获取不到的，只能自已修炼和拿捏-不多不少，一切刚刚好。