大家好，欢迎来到停止重构的频道。
截至上一期,我们已经把前端、后端、云计算三个需要编码的部分介绍完了。
从本期开始，我们将从宏观讨论大型网站系统的整体架构。
开发完了一个大型网站系统的功能，以为熬出了头，但往往的结果是：它的安全检测结果不及格 、或者压力测试发现达不到10万在线用户的要求、 或者运行一段时间就会崩溃 、或者频繁被攻击，凭白多交几十万的CDN流量费。
导致无穷无尽的修复，甚至需要局部重构。这些出乎意料的工作量也只能让团队996、007加班了，但其实这些工作量是可以消融在开发过程中的。
本期，我们先介绍一下整体架构需要解决的问题，大型网站系统的整体架构需要解决的问题有5个：
-
性能
-
可用性
-
弹缩性
-
扩展性
-
安全性
性能
总的来说，网站系统的性能问题可以归结为两个具体问题：
-
网站系统的响应速度是否足够迅速 ；
-
网站系统能否支撑足够多的同时在线用户。
衡量网站系统的性能指标有 响应时间、吞吐量、并发量等 通过压力测试和稳定性测试，可模拟预期的用户量，测试性能是否达标。
很多时候，刚上线的平台频繁崩溃 ，往往就是对性能测试的不重视。
很多时候，开发团队只会想着完成功能，只要完成功能就算是完成任务，但是软件最终是给一群人用的，如果平台崩溃，或者响应速度需要几十秒，那么功能再强也没有用。
性能问题无处不在，性能调优也是一个长期的工作。
但是，这不意味着功能开发和性能调优是完全分阶段完成的，也就是说，不要把性能问题全部放在上线前或试运营阶段才解决。
因为一些诸如集群化、读写分离、缓存等性能优化问题可能涉及到大量的编码工作 ，如果在开发过程中不重视 ，很有可能因为调优工作量过大而推迟上线或交付。
我们曾经看见过一个项目性能调优足足花了1年， 就是因为开发时不重视，仅以功能列表为目标。
后续我们将出专门的内容讨论性能，将会介绍性能调优的思路和开发过程中需要注意的问题 。
可用性
可用性可以理解为稳定性，每个系统都希望能每天24小时正常运行，但事实上 ，系统总会出现一些程序错误或者服务器故障而导致宕机。
很多时候，这些服务器宕机不一定是程序BUG造成的。例如，服务器运行半年，可能内存莫名其妙丢失了一块数据导致宕机，共享文件服务器的磁盘（机械盘）由于长时间高频写入，导致磁盘损坏等。
也就是说，服务器宕机本身是一件难以避免的事情， 所以为了让系统每天24小时正常运行 ，高可用、灾备的设计被提出。简单地说，就是当一部分服务器宕机后， 备用服务器可以马上接替工作。
当然，除了高可用、灾备设计，还需要有完整的服务器监控体系以及定期巡检维护，后续我们将出专门的内容讨论可用性，将会介绍稳定性测试的思路和高可用设计的问题。
弹缩性
一个平台的在线用户是不可能每个时段都是恒定的，可能由于运营活动某几天的在线用户量激增。
如果永远保持满足峰值在线用户量的服务器数量的话，则无疑是浪费资源。
因此，大部分的大型网站系统都需要实现自动弹缩服务器， 以动态适应在线用户量。这时候，估计有很多小伙伴会一笑而过 K8S、容器、公有云 都可以很简单地实现服务器自动弹缩。
这些方式确实可以依照CPU、内存、带宽等附载情况自动增减服务器， 但是，这样是不能让系统性能更高的。
你一定听说过：一些平台做大型活动， 第一天由于用户太多停运了 ，过几天增加了几万台服务器没几个小时又停运了。
其实服务器弹缩并没有一些云厂商、技术论坛讲得这么简单 ，其难度在于数据服务上。 以数据库MySQL为例，根本实现不了真正意义上的自动弹缩服务器。
扩展性
扩展性指的是当网站系统需要扩展或变更功能时 ，应该有条不紊地响应这些变化。扩展性更多是取决于软件质量和软件架构。
如何像USB一样热插拔一个功能模块是我们正在探索的方向， 请期待我们后续发布的开源项目。
另外，除了以上关键因素以外 还需要有科学的发布流程，如分离开发、测试、生产环境 搭建CI/CD自动发布流程等，后续将会出专门的内容对其进行讨论。
安全性
安全性指的是系统对恶意访问、恶意攻击等的抵抗性。
-
一方面是保证系统正常运行；
-
另一方面是保证数据不被泄漏。
近年来， 用户数据泄漏的事件对平台的影响是很大的。
安全性问题大多是一些琐碎或者经常被忽略的问题，后续将会出专门的内容讨论系统安全 ，介绍防SQL盲注、接口鉴权、安全渗透测试等问题。
总结
任何的网站系统，并不是单纯地开发功能就可以了，还有诸如性能、可用性、安全性等非常关键的问题。
如果在开发之初完全忽视这些问题，那么，很有可能在项目后期会出现很多意料之外的的工作量，以为要熬出头了，谁知道不知不觉掉进了深渊，最后项目进度完全失控 、成本超支也是常有的事情。
2078
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
