网站架构功能做完还要加班性能安全

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

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

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

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

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

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

性能

可用性

弹缩性

扩展性

安全性

性能

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

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

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

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

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

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

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

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

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

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

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

可用性

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

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

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

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

弹缩性

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

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

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

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

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

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

扩展性

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

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

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

安全性

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

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

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

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

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

总结

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

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

转载请注明：http://www.abuoumao.com/hyls/1660.html