探讨B/S与C/S架构的区别
前言
这几天听课，听到关于B/S架构和C/S架构的东西，颇有感触。边查阅资料边写了这篇随笔。
C/S架构
C/S架构是比较早期出现的一种系统设计架构。曾经出现过两层C/S和三层C/S架构。我们一般常见的以两层C/S架构为主。我们大家在使用计算机软件过程中基本上一定会遇见C/S架构，例如我们玩的PC游戏几乎都是C/S架构。
C/S架构最大的特点就是会有一个客户端，而且客户端会处理很大一部分逻辑，然后再将数据同步至服务端，由服务端实现剩余逻辑和数据的持久化。
有这个图片可以了解到，市面上大部分app也是使用的C/S架构思想。
C/S的优缺点
优点
- 客户端辅助完成业务逻辑，减少服务端对逻辑的处理。例如一些图画效果的处理，如果这部分都有客户端处理无疑客户端要崩溃。
- 权限较大。由于有客户端的部分，无疑开发时的权限会比B/S架构大，做过B/S的应该都了解在B/S的前端想操作一个本地文件有多难。
- 传输较为安全。因为是客户端与服务端点对点传输，数据的传输较B/S可靠不少。
缺点
- 跨平台支持性差。市场上计算机的型号不一，CPU的架构也不同，操作系统五花八门。这直接导致C/S在开发客户端的时候很难兼容所有设备。
- 升级困难。由于客户端包含大量逻辑处理，那么升级的时候就必须要求用户通过打补丁，或者重新安装客户端的方式升级客户端。这个对于一些用户来说无疑非常不友好。这个缺点也是我认为C/S架构最大的缺点。
- 服务端对数据校验的要求。由于客户端会处理一部分业务逻辑，那么也就导致可能传输假的业务逻辑处理后数据到服务端的可能性，最常见的就是游戏外挂。这就要求服务端对数据的正确性的监控。例如一个游戏角色数据是很差的装备，但是伤害数据却有好几百万，那么就有理由怀疑篡改数据了。
B/S架构
B/S架构出现的背景是互联网的流行，网速带宽的增大，以及近几年云服务的普及无疑进一步促进了B/S架构的发展。
B/S架构最大的特点是不需要单独下载一个客户端，而是使用浏览器作为用户操作的接口。前端部分只做数据的展现，并且只做非常简单的逻辑处理，大部分的业务逻辑处理都有服务端来处理。
B/S大致会分为三层：
- 数据展现层。载体是浏览器，用以对用户展现数据和提供操作接口。
- 业务逻辑层。载体是服务器，用来处理用户提交和业务逻辑处理。
- 数据持久层。载体是数据库，用来将逻辑处理结果进行持久化。
个人觉得非常类似MVC的设计模式，但是两者是从不同维度考虑问题的，不应该将二者混淆。
B/S的优缺点
优点
- 升级维护成本极低。由于用户主机上并没有客户端，因此升级更新维护往往是一次更新全用户同步的。
- 兼容性强。这个就有点类似虚拟机的概念，我们只开发在浏览器（类比虚拟机）上可以运行的程序，而用户只需要安装可以运行程序的浏览器即可，兼容性由浏览器来处理。
缺点
- 数据交互不安全。由于大部分B/S的数据传输是HTTP协议的，这就导致传输的不可靠性，许多的加强数据安全性的协议也是由此而来的。
- 客户端权限低。由于程序将在浏览器上运行，那么权限将由浏览器来限制。
总结
不得不说在我们计算机领域是没有绝对的架构的。一个软件往往是B/S和C/S架构的混合，而作为架构思想，他们的标准由没有非常明确的分界线。例如我们一个手机App往往是WebView和原生Activity混合的产品，再例如我们的一些WebApp，往往也会有很多会处理一部分业务逻辑，处理之后再同步到服务器，那就很难区分他们到底是B/S或者C/S架构了，非要说的话，也只能说是主要采用了某种架构，而不是纯粹的采用了某种架构。
