大家好，欢迎来到停止重构的频道。

截至上一期,我们已经把前端、后端、云计算三个需要编码的部分介绍完了。

从本期开始，我们将从宏观讨论大型网站系统的整体架构。

开发完了一个大型网站系统的功能，以为熬出了头，但往往的结果是：它的安全检测结果不及格 、或者压力测试发现达不到10万在线用户的要求、 或者运行一段时间就会崩溃 、或者频繁被攻击，凭白多交几十万的CDN流量费。

导致无穷无尽的修复，甚至需要局部重构。这些出乎意料的工作量也只能让团队996、007加班了，但其实这些工作量是可以消融在开发过程中的。

本期，我们先介绍一下整体架构需要解决的问题，大型网站系统的整体架构需要解决的问题有5个：

1. 性能 

2. 可用性 

3. 弹缩性 

4. 扩展性

5. 安全性 

性能 

总的来说，网站系统的性能问题可以归结为两个具体问题： 

• 网站系统的响应速度是否足够迅速 ；

• 网站系统能否支撑足够多的同时在线用户。

衡量网站系统的性能指标有 响应时间、吞吐量、并发量等 通过压力测试和稳定性测试，可模拟预期的用户量，测试性能是否达标。

很多时候，刚上线的平台频繁崩溃 ，往往就是对性能测试的不重视。

很多时候，开发团队只会想着完成功能，只要完成功能就算是完成任务，但是软件最终是给一群人用的，如果平台崩溃，或者响应速度需要几十秒，那么功能再强也没有用。

性能问题无处不在，性能调优也是一个长期的工作。 

但是，这不意味着功能开发和性能调优是完全分阶段完成的，也就是说，不要把性能问题全部放在上线前或试运营阶段才解决。

因为一些诸如集群化、读写分离、缓存等性能优化问题可能涉及到大量的编码工作 ，如果在开发过程中不重视 ，很有可能因为调优工作量过大而推迟上线或交付。

我们曾经看见过一个项目性能调优足足花了1年， 就是因为开发时不重视，仅以功能列表为目标。

​后续我们将出专门的内容讨论性能，将会介绍性能调优的思路和开发过程中需要注意的问题 。

可用性 

可用性可以理解为稳定性，每个系统都希望能每天24小时正常运行，但事实上 ，系统总会出现一些程序错误或者服务器故障而导致宕机。

很多时候，这些服务器宕机不一定是程序BUG造成的。例如，服务器运行半年，可能内存莫名其妙丢失了一块数据导致宕机，共享文件服务器的磁盘（机械盘）由于长时间高频写入，导致磁盘损坏等。

也就是说，服务器宕机本身是一件难以避免的事情， 所以为了让系统每天24小时正常运行 ，高可用、灾备的设计被提出。简单地说，就是当一部分服务器宕机后， 备用服务器可以马上接替工作。​

当然，除了高可用、灾备设计，还需要有完整的服务器监控体系以及定期巡检维护，后续我们将出专门的内容讨论可用性，将会介绍稳定性测试的思路和高可用设计的问题。

弹缩性 

一个平台的在线用户是不可能每个时段都是恒定的，可能由于运营活动某几天的在线用户量激增。

如果永远保持满足峰值在线用户量的服务器数量的话，则无疑是浪费资源。

因此，大部分的大型网站系统都需要实现自动弹缩服务器， 以动态适应在线用户量。这时候，估计有很多小伙伴会一笑而过 K8S、容器、公有云 都可以很简单地实现服务器自动弹缩。

这些方式确实可以依照CPU、内存、带宽等附载情况自动增减服务器， 但是，这样是不能让系统性能更高的。

你一定听说过：一些平台做大型活动， 第一天由于用户太多停运了 ，过几天增加了几万台服务器没几个小时又停运了。

其实服务器弹缩并没有一些云厂商、技术论坛讲得这么简单 ，其难度在于数据服务上。 以数据库MySQL为例，根本实现不了真正意义上的自动弹缩服务器。

扩展性

扩展性指的是当网站系统需要扩展或变更功能时 ，应该有条不紊地响应这些变化。扩展性更多是取决于软件质量和软件架构。

​如何像USB一样热插拔一个功能模块是我们正在探索的方向， 请期待我们后续发布的开源项目。

另外，除了以上关键因素以外 还需要有科学的发布流程，如分离开发、测试、生产环境 搭建CI/CD自动发布流程等，后续将会出专门的内容对其进行讨论。

安全性 

安全性指的是系统对恶意访问、恶意攻击等的抵抗性。

• ​一方面是保证系统正常运行；

• 另一方面是保证数据不被泄漏。

近年来， 用户数据泄漏的事件对平台的影响是很大的。

安全性问题大多是一些琐碎或者经常被忽略的问题，后续将会出专门的内容讨论系统安全 ，介绍防SQL盲注、接口鉴权、安全渗透测试等问题。

总结 

任何的网站系统，并不是单纯地开发功能就可以了，还有诸如性能、可用性、安全性等非常关键的问题。

如果在开发之初完全忽视这些问题，那么，很有可能在项目后期会出现很多意料之外的的工作量，以为要熬出头了，谁知道不知不觉掉进了深渊，最后项目进度完全失控 、成本超支也是常有的事情。