架构演变历史--0817

开发的终极目标--架构师

首先我们看什么是架构师？架构师应该具备哪些能力？

大家都知道很多公司都有架构师这个职位，但是我想告诉大家的是看一个人是不是架构师不是看职位，而是看他所具备的能力以及正在做的事，所以有架构师头衔的人不一定具备架构师的能力，而不是架构师的人却在做着架构师的工作。
架构师类似于建筑行业的总设计师，通常在一个软件项目中，架构师需要完成软件项目中所有技术环节的设计，架构师虽然说不用亲自编写所有代码，但是架构师会对项目中所有运用的技术环节了如指掌。
因此架构师既可以是一个很简单的工作，也可以是一个具备超高难度的工作。而具体的难度系数，取决于具体的项目类型。就好像盖一个两层小楼，和一个跨海大桥，对架构师的要求截然不同。

1.png

比如说我们现在目标任务是开发一个自主品牌的mp3播放器，我们的架构师需要懂硬件，比如单片机,传感器，声音设备，再利用汇编或者C语言，来对该电子系统编写相应的程序，就可以完成这样的一套mp3程序开发。
但软件的架构师在不断进化着，在计算机发明的初期，几乎大部分应用程序都是直接针对硬件来编写的，但是这样会导致程序的通用性差，所以才出现了操作系统。在目前市场上流通的大部分软件都是工作在操作系统之上的。
因此我们可以看见第二张图的这样的架构。

2.png

编写这样的应用程序需要我们架构师了解硬件，了解操作系统，并且能够使用C，C++，VB，等编程语言调用操作系统SDK完成软件功能开发。由操作系统去跟硬件系统打交道，这样对于开发人员的要求就降低了很多，同时应用程序的通用性会变得更好。
再看看第三张图

3.png

随着计算机软件的发展，我们发现很多软件都是在和数据打交道，用户数据需要记录到系统中，同时应该能快速的检索数据，因此在我们的单机应用中出现了数据库这么一类应用程序。在需要存储数据，搜书数据，以及对数据加工处理统计的时候可以把这些工作交给数据库去处理。
做这类应用软件的开发工程师，对硬件和操作系统了解即可。需要他精通数据库，并且能用任意语言调用系统提供的SDK。
在看看第四张图

4.png

这个是C/S应用程序架构，这里的客户端架构与第三张图单机应用类似，唯一不同的是在数据的来源的上作出了改变。原本的单机应用程序数据存在本地，但是一个软件系统如果有多人使用多个客户端连接的时候，不可能把数据库再放到莫一台客户机中。
解决方案就是让数据库通过网络对客户端提供数据服务。直接通过客户端远程连接直接操作数据库这种方式也是不可以的，因为数据库如果直接对外提供数据服务，那么凡是能连接到该网络的用户都可以绕过客户端操作数据库，这样数据安全就得不到保障。
因此出现了Server，我们通过服务器端程序来操作数据库，客户端程序只能选择与服务器端交互，所有的业务操作由服务器端完成，这种模式就是C/S架构。
完成C/S架构的架构师就比做单机应用的架构师难度大很多，不仅要懂得单机应用开发所需要的知识，还需要掌握网路数据库系统，以及web服务，socket服务等技术。
C/S应用程序架构存在一些缺点：需要更新所有已安装的客户端版本，而且会出现多个版本并存的情况，后期维护代价极高，而且很不方便。
因为这些原因，就出现了B/S这些架构的软件。

5.png

如图所示，我们可以看到此架构的服务端与第四张的服务器端基本一致。主要区别是B/S架构的应用程序不需要安装客户端程序，而是使用大部分的计算机都有安装的浏览器来作为系统前端来与用户交互，而浏览器加载的内容全部来由服务端输出.
这样B/S的架构师难度相对来说比C/S架构师低很多，并且有诸多的成熟的解决方案，比如：java的javaee架构，微软的asp.net架构，完全开源的lamp架构，都是很成熟的解决方案。
这样架构的优点在于因为存在大量的成熟的解决方案，只需要一台可连入网络的服务器，就可以让整个系统运转起来。开发速度快，运营成本低。这种解决方案被广泛接纳。所以做这样架构的程序员数量很多，也因此往往不被当做架构师来看待。但是做这样架构的应用程序设计也架构设计中的一种。
我们来看第6张图

6.png

从2010年以后，智能手机在国内大量普及，几年时间诞生了数百万的App与手机游戏，往往一个项目既拥有自己的网站，又拥有独立的APP，而且作为一个整体的系统，iOS，安卓，与网页的数据应该是一致的。
那么要做到这样的架构设计的话，我们需要让我们的ios，安卓客户端共用我们的服务端，这样我们的多端才能保持数据高度一致。
服务器端的结构没有太大的变化，但是软件设计的方式产生了变化，原本B/S架构中由服务端向浏览器输出相应的html，css，js等静态内容即可，但如果涉及到移动互联网应用开发，我们会将我们的应用程序规范化，把前端和后端完全区分开来。
服务器端提供数据交互服务，并编写相应的接口，移动端进行接口调用，并完成界面数据填充以负责用户交互，即便是移动端浏览器，也应采用这种方式来交互。
接下来看第7张图

7.png

它和6张图比较类似，但多出来几块。我们把横线以上的部分叫服务端，横线以下的叫前端。我们在移动互联网络时代，经常会涉及到自己的平台与第三方平台的交互，我们的应用在接入支付宝，微信，微博等功能后，还会涉及到与第三方平台的功能交互。
通常需要我们通过服务器发起请求调用第三方的API，并且为第三方的平台保留回调的接口，因此在制作这样的应用程序开发的时候，架构师除了要掌握移动互联网络的技术外，还需要对第三方提供的功能与规范以及相应接口有充分的了解。
来看第8张图

8.png

如果只是从功能实现来说，能够按照第7张图完成架构设计的架构师，已经能满足需求。但是在实际运营的项目中，除了有功能需求以外，还要有质量需求，比如：网站的负载能力，网络并发连接数，系统的数据吞吐量，项目是否具有扩容能力等。
之前所展示给大家的所有架构，都是基于单服务器架构来设计的，如果只有一台服务器，无能我们怎样花钱来升级他的硬件配置，我们会发现很快将无法进一步扩容。最好的CPU，最大的内存条也是有限度的，因此采用集群架构，才是解决问题的正确方法。
而第8张图所画的就是标准的分布式集群架构，集群的扩容原则就是一个人干不完的活多个人一起干，让服务器与服务器之间，进行分工与协作。2
而做分布式集群的架构的架构师，也有着较高的要求，而互联网上受人敬仰的架构师大多属于这类。你也可以认为这才是真正的架构师。
看第9张图

9.png

服务器端同第7张，第8张可以是一致的，具体是选择哪个服务器的架构，取决于项目的规模。项目初期用户量少，可以选择单服务器架构，如果项目后期服务器负载压力过大，可以重构为分布式集群架构。
第9张图的重点在于项目前端，我们来看前端的技术架构图，这里所画的是市面所流行的混合APP的架构。
著名的混合APP应用有很多，比如说支付宝手机客户端，还有Facebook，这些应用都是采用混合APP架构设计的。
混合APP应用使用html，和css打造用户界面，无论是在浏览器，微信端，还是在APP中，都是如此。因此他具备B/S应用程序的优点，可以在服务器端更新应用内容，并且让应用在ios，安卓，浏览器端保持高度一致性。
利用单页web APP开发技术，能够让网页程序像原生应用一样流畅，而web APP的缺点在于，网页js程序无法调用手机硬件功能，但是混合APP架构可以通过微信sdk，微博sdk ，iOS bridges，安卓bridge是等方式来获取微信APP，微博APP以及手机硬件的功能。
因此混合APP架构同时具备了web APP与原生应用的优势，成为了市场上主流的移动应用架构设计方法。跨平台兼容性好，开发成本低，开发速度快。逐步取代了大量的原生应用。这也是我们兄弟全栈工程师学习的主要内容。