Spring 源码分析(四) ——MVC（一）Web 基础

随时随地阅读更多技术实战干货，获取项目源码、学习资料，请关注源代码社区公众号(ydmsq666)

from：https://my.oschina.net/kaywu123/blog/644836

软件的分类

        软件（Software）是一系列按照特定顺序组织的计算机数据和指示，是计算机中的非有形部分。而计算机中的有形部分称为硬件，由计算机的外壳及各零件及电路所组成。计算机软件需要有硬件才能运作，反之亦然，软件和硬件都无法在不互相配合的情况下进行实际的运作。

        一般来说，计算机软件被分为编程语言、系统软件、应用软件和介于两者之间的中间件。其中系统软件为计算机使用提供最基本的功能，但是并不针对某一特定应用领域。而应用软件则恰好相反，不同应用软件根据用户和所服务的领域提供不同的功能，也可以根据软件结构分成：单机类型、C/S类型和B/S类型三种不同的类型。因为网站架构才是我们这次研究的重点，所以我们就对应用软件进行专门分析。

        基本上不需要联网的应用软件，都可以归类为单机类型，比如我们常见的Office、搜狗输入法、单机游戏等等。这种软件类型简单、使用起来也非常广泛，可以说是应用软件的鼻祖。

        而有些应用软件需要将应用程序中的数据进行统一管理，所以我们必须将保存数据的数据库统一放在一台主机中。这样所有的用户就可以从同一台主机中获取数据了，这时就分客户端和服务端了。用户安装的软件叫客户端，统一管理数据的主机就叫服务端，而这种软件结构就叫C/S结构。通常情况下，如果将业务逻辑全部都放在服务端进行统一处理就可以获得更好的安全性和稳定性而且软件升级也比较容易，但这会加重服务端的负载。反之亦然，如果将业务逻辑放在客户端这样就可以降低负载，但安全性、稳定性以及软件升级都成了问题。所以，在C/S结构中合理的进行的业务逻辑的分配就是一件仁者见仁智者见智的事情了。下面是C/S的结构图：

        其实，C/S结构已经完成了网络通信了，但为了解决刚才所提到了不足，设计者将客户端进行了统一的整合，而且默认安装在客户的计算机中，这就是"浏览器"。客户通过浏览器访问不同的页面，进而完成不同业务逻辑并且进行完成数据交互，这种软件结构就是B/S结构。下面就是B/S的结构图：

        其实，这三种结构谈不上谁好谁坏，一般根据需求而定。B/S结构开发简单、使用方便而且功能强大，所以使用最为广泛。但单机结构的软件基本上是每台计算机上都会有。而C/S结构虽然比B/S复杂，但灵活性和处理效率都要比B/S高出许多，所以现在一些大型的软件和游戏基本使用的还是C/S结构。下面我们就来论述一下关于B/S结构的基础知识。

网络传输模型                                         

        在讨论基础架构前，我们我们必须先了解一下底层网络传输体系，毕竟网站是建立在互联网之上的，有些专门地通讯协议也需要特别注意一下。一般网络传输的分解方式有两种：一种是 OSI 参考模型，一种是 TCP/IP 参考模型。下面是它们的分成方法及对应关系图：

        OSI 参考模型一共分为 7 层，不过它主要用于教学，所以笔者不做阐述。实际使用中更多的是 TCP/IP 的 4 层模型。对于 TCP/IP 的 4 层模型可以简单地理解为：

                网络接入层：将需要互相连接的节点接入网络中，从而为数据传输提供条件。

                网际互联层：找到要传输数据的目标节点。

                传输层：数据传输数据。

                应用层：使用接收到的数据。

        下面是 TCP/IP 4 层模型的层次图：

        对于互联网这种使用广泛的东西，标准是非常重要的，但是在传输参考模型中，这种制度不叫标准而是协议。在 TCP/TP 模型中网络接入层是没有协议的，而重要的协议，在网络互联层是 IP 协议，传输层是 TCP 协议，应用层是 HTTP 协议，当然还有 DNS 协议和基于 HTTP 上层的相关规范也就是 Web 中的 Servlet。 

网站架构的演化

        我们都知道现在的 Web 软件都是基于 B/S 结构的，所以将 B/S 结构做一些小小的改动，就是一个小型网站的架构，当然是最原始阶段的网站架构。小型网站最初的时候并没有多少访问量，一台应用服务器或者将应用服务器拆分成应用服务器和数据库服务器，基本就已经很够用了。下面就是最简单的网站架构图：

        将应用程序、文件等等放在一台应用服务器上，而数据库则在另一台数据库服务器上。通常服务器操作系统是 Linux，应用程序使用 PHP 或者 Java 进行开发，然后用 Tomcat 或者 Apache 进行部署，数据库使用 MySQL，最后汇集各种免费开源软件以及廉价的服务器就可以开始运营了。

        当然，随着业务规模的发展，服务器肯定不够用的，这时就需要添加新的服务器，来进行应用与文件的分离了，并且需要遵循“二八原则”添加专门地缓存服务器来改善网站的性能。但如果出现了高并发加海量数据的情况，最常用的手段是使用集群加数据库读写分离的方法来解决，当然，使用反向代理和 CDN 提升网站性能也是必不可少的环节。至此，一个基本分布式系统就算是建立起来了。当然，这样的架构其实还是可以继续进行优化的，比如使用非关系型数据库、进行业务拆分以及使用分布式服务等等。这个世界没有哪个网站从诞生开始就是大型网站，所以一味地追求网站架构是一种得不偿失的行为。但随着业务的增长，推动网站架构的演进还是非常有必要的，因为这样你才能随心所欲的去应对各种情况。

        性能、可用性、伸缩性、扩展性以及安全性是网站架构最核心的几个要素，基本这些问题解决了，网站架构的大部分困难也就克服了。此外，这个世界没有哪两家公司的业务情况是完全相同的，所以在架构演化的道路上绝对不能盲从。不要受大公司以及从大公司挖过来的技术高手的太大影响，从而偏离了原先的架构演化路线。大公司的经验和成功模式固然很重要，但盲目借鉴，可能会偏离符合实际的架构演化道路。也不能为了技术而技术，一味追求最新技术，只会让架构之路越走越难。最后有时候，问题并不是出在它的系统架构，而是业务架构出了问题，所以，合理地调整业务需求往往比修改架构更为有效。

        总的来说，在网站架构演化的过程中，追求技术是为了扩展业务边际，架构设计与业务一定是相辅相成的。

——水门（2016年3月写于武汉）