原创作品，出自 “深蓝的blog” 博客，欢迎转载，转载时请务必注明出处，否则追究版权法律责任。
深蓝的blog：http://blog.csdn.net/huangyanlong/article/details/47802553
【前言】
自接触oracle至今，愈是深入了解oracle愈是察觉到个人的渺小，时常感受到技术知识可以助推思维方式，一路走来，在汗水中收获着成长的充实，不仅局限于oracle技术，借由此系列文章，分享个人在追逐DBA道路上收获的些许感悟与成长的点滴记录。在浩瀚星空里，鉴证自己人生中那一道弧线。
一次锻炼，一次赶鸭子上架，学习和收获。
——深蓝
看来看去，自己的照片怎么有点呆滞，忘记摆个好点的POSE了。
——深蓝
前段时间，原定于是让研发兄弟为客户做一次系统平台的介绍，恰巧赶上兄弟的婚期，于是我就硬着头皮上了。没成想，会议时间是一推再推，也没成想，客户把会议阵势玩的也越来越大。竟然事已至此，就算不想上，也只能想办法学习上了，而且是上不了硬上了。
于是利用工作的闲暇时间开始了解业务系统的功能、软件的框架体系、操作亮点及重要功能等等，顺带手整理着简单的PPT。经过几天的摸索，终于对软件系统框架有了一次飞跃式的认识。再伴随着由于长期跟着这个项目建设，客户思维里，没有太多前端、后台数据的这种划分，全然的我们这里的工作人员，都是开发。于是开始或多或少、或浅或深的接触到、了解到什么表单、布局、框架、方法、调用、类等等的开发知识。很多东西联想到已经n年没触碰的硬件研发知识，发现有很多思路到是如出一辙啊。有那么一点点认识到，学习知识，不能停留在操作，而是多的去培养意识、思维方法这其中的道理与原因了。
对于软件框架，不知道是不是之前有了“oracle体系结构图”的思维模式，在看到软件的框架图时，并没感觉到设想的难度，直观的体会到应用软件框架，更多的是一种高度结合业务功能、子系统的功能性划分、接口的串联功能性的挂接等等，整体看来就形成了这么一个框架结构图。
虽然做了些准备，但业务逻辑上、功能模块上，仍然有很多知识盲点。在对一些逻辑实现上理解还是停留在皮毛。所以啊，有惊无险的一次系统介绍，比较浅显的介绍了一下软件实现，用意在于让客户对系统有一次更感性的认识。这期间被客户打断四次，其中三次问及的一些业务知识，现场就冒冷汗了~硬着头皮在那绉。好在客户中也有技术领导的帮忙、还有我方销售大哥的帮助，还好是能应付过去了。也深深感叹到，对于一个系统的全面认识、对于业务的经验累积，对于了解和把控一个软件系统是何等的重要。
谈到PPT的设计套路，还是老三样，无论是学校期间的论文、答辩，还是工作以后的软件介绍、技术学习。开篇都是先来描述背景、目标、任务这类基础知识。这么做是为了让听讲者有一个清晰的逻辑认识，也是在给讲演者缓解紧张、适应讲演环境做一个平滑的过度。当然，最重要的是，开篇的几页PPT也是为了让知识体系看起来更全面、调理性更清楚，是一个介绍思路的引领。
当然，我们的资料是不能在这公开的，这里不写点出来又觉得少点啥，那就把产品假设成oracle吧。在下面，我就以oracle技术为背景，做一次oracle背景、目标、任务的例子吧。
如果准备oracle介绍，我想思路上是把数据库的发展史、RDBMS的发展过程、oracle及各类数据库之间的关系介绍一下吧。思路上分几小点，如下：
1、数据库历史；
2、主流数据库；
3、oracle的介绍。
而第二页呢，就是项目目标性的东西，首先要让听众明确“目标”是什么，这样，后边就有针对性的扩展了。
对于oracle，似乎针对于不同的技术，有不同的目标性，这里就从宏观角度去切入吧。
1、高可用、负载均衡：RAC；
2、容灾性：DG；
3、数据同步：OGG；
4、一体化：Exadata。
对于任务来说，其实是结合目标后的大方向，落实到实实在在的流程上，去逐一的总结滤清整个任务流程来。
比如说如果是想在LINUX5平台下，搭建一套Oracle11G双节点的RAC，具体的任务流程有哪些呢？这里把任务的操作流程做一个思路上的列举。
1、安装前系统规划；
2、安装系统配置；
3、配置共享存储；
4、建立主机间信任关系；
5、安装前环境校验；
6、安装Grid；
7、安装Oracle软件；
8、创建ASM存储；
9、用DBCA完成建库；
如果能这样总结出来，想必对于实施流程已经思路很明确了，会感觉一路下来原来如此简单。
对于制作一个讲演用的PPT，大体上在开始时候，就像是一个套路，无外乎是针对于介绍方面的知识，就是这样。
后面的内容，便是想要介绍一下我们系统的平台架构了。
用户更关注“功能需求”，平台架构，底层设计，客户不关心。
——深蓝
应用框架如何设计跟业务要求、客户需求是分不开的。一个应用产品的分析师、架构师如何，将影响到整个产品的开发、应用周期。如果想要征服用户，需要全面透彻的了解产品。对产品功能上有一个比较深入的理解，这样无论是业内交流还是讲演传授，才会让听者更为信服。然而对于一个专注于后台建设的工程师，对于底层的架构，其实让我准备的话，就足以填满这短短的一个小时了。因为我们总是会对自己亲身实践过的方面、擅长的技术方面，印象深刻，才能有的说。但是针对的讲演群体的不同，所以阐述的内容也要有所调整，于是我把平台底层架构，诸如数据库集群、应用集群方面的内容全都给砍掉了（因为说了客户也不懂呐，客户那已经有很多不懂的了，如果再说这个，这不是添乱嘛，嘿嘿~~）。关于平台架构，仍然在继续摸索、学习阶段。这里呢，做一个自我总结、自我反省、自我学习的重现吧。说些个人见解、观点、整理些学习杂记，读者看来时，全当扩展视野，不必太过当真。如果有幸让牛人、大师读到，就请原谅晚生的班门弄斧、卖弄献丑了。我全然把这当成是“自我学习”了。
举一个简单的架构设计拓扑，如下：
这个方案设计，数据库使用oracle集群2节点方式。备份专设了一台备份服务器。生产数据、备份数据分别使用存储进行存储。同时配有业务上所需要的数据的抽取、上传服务器。对于应用层面，这里配设了四台应用服务器，来满足高并发访问。
这里由于预算问题，原定使用光纤交换机的方案没被使用。在没有光纤交换机的情况下，临时做了变通，采取了这种连接数据库存储和备份存储分别通过光纤跳线进行了直连，在这里算是一处败笔吧。因为每台服务器采购时都配置了HBA卡，却没有准备光纤交换机，钱被花了，而实际硬件却没落实，当我们看到这样的设备时，我们也是醉了。虽说没完全按预期搭建，但好在这次搭建后使用尚未收到影响。
下面对细节的知识做一下简单介绍。
“应用服务器”和“数据库服务器”的分离部署。
在业界这是最为常见的部署架构。原因很简单，当我们把应用服务器与数据库服务器分离部署时，会有诸多的优势。
首先，对于安全性有一定的保障。因为我们可以对我们访问应用所使用的网络建立一个局域网，而对于数据库服务器则可以与应用服务器分离此局域网，使用另外一套私网，而保障了数据库网络层不在应用局域网内出现。
其次，应用服务器只负责应用访问，而数据库服务器只负责处理数据，这两者有着明显的性能分工，分离部署将最大化的提升性能，减少性能损耗。
下面，先了解了解基本的硬件设备：
对于服务器，我们常常听到几U的这类问题，外行人或许觉得这是个专业知识，但其实这个没啥，U就是单位，几U指的就是规范的标准、规格而已。
1U=4.45cm
2U=8.9cm
3U=4.45cm * 3
4U=4.45cm * 4
对于硬件层面的了解，往往直观的实体产品才能给我们足够的印象，下面通过截取的几张图片来对硬件设备简单列举。
对于服务器，看看在网上找到的信息。支持一下国货吧，找来几个浪潮的网上报价，我们简单来看一下。
例：浪潮服务器NF8560M2
例：浪潮服务器NF5270M3
这是通过连接光纤线连接存储的设备卡。
华为S5700S-28P-LI
举个例子：浪潮AS500E
服务器可以分为X86服务器和非X86服务器。服务器是信息系统的核心设备之一。它主要体现在稳定性、可靠性、处理能力、安全性、可扩展性、可管理性等方面，都要远强于PC。
简单列举一下X86与非X86，如下：
|
项目点 |
x86服务器 |
非x86服务器 |
|
处理器芯片 |
使用intel或其它兼容x86指令集的处理器芯片，又称CISC（复杂指令集）架构服务器，采用windows操作系统 |
使用RISC（精简指令）处理器，采用UNIX或其它操作系统 |
|
服务器种类 |
PC服务器 |
大型机、小型机、Oracle小型机、UNIX服务器等 |
|
价格 |
较便宜 |
较昂贵 |
|
性能 |
兼容性好、稳定性较差、安全性较低 |
稳定性好、性能强、安全性高 |
|
应用场景 |
中小企业、非关键业务系统 |
大型企业、核心业务系统 |
补充：
精简指令集处理器主要有IBM公司的power和PowerPC处理器、hp公司研发的PA-RISC处理器、sun与富士通研发的SPARC处理器。
补充完毕。
存储设备顾名思义是用于存储信息的设备。通常是将信息数字化后再存储到电、磁或光学等方式的媒体中。由于当今IT技术的不断发展，对于日益增长的业务数据来说，普通的存储设备已经满足不了我们的需求。为了满足存储大容量数据，存取数据速度快，设备可靠性要求高，成本可控等要求，于是RAID（redundant arrays of inexpensive disks）技术、SAN（storage area network）存储区域网络、NAS（network attached storage）网络存储设备、磁带库等技术应运而生。
这里暂且只对磁盘阵列RAID技术做一下简单的介绍：
|
RAID技术 |
简述 |
|
RAID0 |
条带（stripe）：高性能 |
|
RAID1 |
镜像（mirror）：高安全，高冗余 |
|
RAID(0+1) |
条带化、镜像 |
|
RAID10 |
RAID0+RAID1 |
|
RAID3 |
具有专用校验盘的磁盘条带化 |
|
RAID5 |
（校验算法）具有分布式校验的磁盘条带化。每块盘数据都可通过其余盘恢复（奇偶校验），提高性能+提高冗余，最多允许1块盘损坏 raid5要是有缓存写入性能也不差，例如oracle数据库的dbwr写入阵列中的缓存（cache），缓存中完成校验，dbwr只负责把脏块写入到缓存里，而剩下的工作就由阵列自行完成了。 raid5只会占用一块盘单位的存储空间（因为校验分布在不同的磁盘上），意味着组建raid5后如果存储容量越大（磁盘越多），性价比越高。 |
|
raid6 |
写入数据时，会建立两套独立的校验信息（允许最多坏两块盘）。 |
|
举例 |
对于RAID技术的应用这里以oracle数据库存储规划列举一个方案： 1、redo raid10：磁盘性能和安全性的要求 2、datafile raid5：安全性一定保障，使磁盘性价比提升 3、archive raid 5：安全性一定保障 前提：raid5构建阵列，要求阵列上带有缓存（缓存很小或没有的话，脏块写入速度将会很慢，性能将会很低）。 |
网络设备是利用通信线路，把各种硬件设备连接起来的桥梁。这里网络设备包括集线器、交换机、路由器、防火墙等等。
我在最初接触网络设备的时候，对于集线器、交换机、路由器这几个设备经常搞混，不知道你是否对这几个设备已经有了清楚的认识呢？
这里做个简单的整理。
|
形象化 |
路由器是爷爷，交换机是儿子，集线器是孙子 |
|
兼容性 |
向下兼容，路由器>交换机>集线器 |
|
工作方式 |
（1）、集线器是一种广播形式的设备，他是把要发送的数据发送到每一个端口来确定该端口是不是目的端口，它与路由器不同在于，同一时刻只能有两个端口传送数据，其它端口只能等待，只能工作在半双工模式下。 （2）、交换机是一种点对点的设备，直接把要发送的数据发送到指定端口。可以把一根网线的带宽平均分配，这样有人下载也不会影响其他人。 （3）、路由器是由路由与交换机的合体，不仅具有交换机的功能而且还具备简单的路由功能，是两个网络之间连接的桥梁，具有拨号功能、防火墙功能、端口映射功能。一些路由器可以通过设置实现交换机的分配带宽功能。 |
对网络基础设备有了一定了解后，下面摘抄了一个网络设备在OSI体系中的分布列表，如下所示：
|
OSI层次 |
地址类型 |
设备 |
|
传送层以上 |
应用程序进程地址（端口） |
网关（协议转换器） |
|
网络层 |
网络地址（IP地址） |
路由器（三层交换机） |
|
数据链路层 |
物理地址（MAC地址） |
网桥、交换机（网卡） |
|
物理层 |
无 |
中继器、集线器（网卡） |
除了上面列表中列举的设备外，网络设备还包括如防护墙，而防火墙又可以软件防火墙和硬件防火墙，以及芯片级防火墙。其中对于硬件防火墙所指的是硬件厂商把硬件防火墙和软件防火墙集成的一体机，厂商会把linux系统与开发的安全软件嵌入到定制的硬件设备中，此类防火墙与软件防火墙最大的区别就在于是否基于专用的硬件平台。对于网络设备除了防火墙，还有VPN也是一种，就是virtual private network的简称，称其为“虚拟私人网络”或“虚拟专用网络”。这是用于虚拟专用网络来连接企业内网专线的设施。
对于网络设备不止有上面介绍的这些，比如有关于交换机就还分为直通式、存储转发式、碎片隔离式等等。再比如路由器也分为模块化路由器、非模块化路由器、虚拟路由器、核心路由器、无线路由器等等。这些就不展开了，感兴趣可以自行baidu一下。
先来说说技术框架，学习一下关于java的三大框架体系：Struts、hibernate、spring。
在对java框架朦朦胧胧的时候，听到一位开发的同事这样跟我解释：三大框架就是一个针对前台，一个针对后台，一个关联起前台和后台。当时，我信以为“真”了（又想黑黑“开发”，常常遇到那么一类人，打着开发的“名头”，总喜欢用着“巴神的世界你不懂”的姿态，在那里大谈开发技能，我这种不懂的人，也就只好鸭子听雷，你说啥就是啥了，嘿嘿）。随着时间的流逝，我开始尝试了解了java三大核心框架。看其外围的一些皮毛，再来说说三大框架到底是个啥？
在对java三大框架有一个浅显的认识后，再来想想研发同事说的，又有那么点“真”了。是不是呢~~
对于java里的框架。最近有幸跟java开发们混迹在一起，对这几个框架有了点初步的认识。简单做图，如下：
对于典型的三大框架是用来开发web应用程序中使用的。Struts是基于MVC（实体层+展现层+控制层）的充当了其中的视图层和控制器。而Hibernate是对JDBC轻量级的封装，通过面向对象的操作访问数据库，也就是所说的底层，数据层，jdbc那方面。最后对于Spring，可以理解成它是把另两个框架管理起来的管理层。在网上还看到说spring框架是采用了控制反转的技术，管理Bean（实体对象类,可以将数据库操作抽象成对类的操作），降低了各层之间的耦合。而从开发那里了解到，对于当前的SPRING框架已经非常强大，其实可以省去Hibernate和Struts两层，来独立的完成关联层、控制器、数据层的任务。就目前java框架的成熟度和种类来说，对于开发人员的选择有很多，更多的考虑就应该去结合实际业务去衡量把控了。我在工作中所接触过的一个例子，也是使用了3层模式。但是表现层使用的是webwork，业务层使用的是spring，数据持久层使用的是mybatis。据说现在对于持久层的使用上，更多的会使用mybatis来实现。这样的设计是使用webwork来管理视图层并对异常进行捕获，由spring框架来管理业务逻辑和事务的管理。mybatis则作为了封装数据及面向数据库的操作与分页等等。以上有道听途说来的一点理论支撑和也有自己的一些肤浅理解，这里作为之言片语表述一下。
C/S模式，客户机/服务器模式（Client/Server）；
B/S模式，浏览器/服务器模式（Brower/Server）。
对于C/S模式，从体系结构划分，可以分成两层和三层。
两层模式，简单如图：
这个简单图例表示了一端的客户端程序，另外一层便是数据库服务器，存储数据的层级。这样形成了典型的C/S两层架构体系。比如说java编写Swing的GUI程序。这个界面交互程序，需要客户来对数据进行录入，并对数据进行格式检查后写入到数据库服务器上的数据库中。同时客户端程序发起某些查询时，还需要从数据库中检索数据。这样GUI程序与数据库组成了一个C/S架构的场景。
而三层模式，再看下面的简图：
上面的这个简单的图就是三层的C/S架构图，与两层的区别就在于，将应用与客户端进行了分离。这样的架构体系，客户机会保留用户界面层软件，负责着与应用服务器之间进行对话的任务；而应用服务器本身会存有真正实现业务逻辑的应用软件，用来响应客户机的请求，用来完成业务处理；而对于数据库服务器，仍然是存放数据的媒介，用来执行由应用层发来的数据库操作任务，最后把结果由应用服务器层返回给客户客户端程序。
简单介绍完了C/S架构的方案。下面再来介绍一下B/S架构。对于B/S架构有些类似于C/S架构的三层模式，但其中的区别在于B/S架构下的客户端只需要安装一个浏览器，就可以通过webserver实现与数据库的交互。简单草图如下：
这样的架构优势非常明显。首先就是用户无需安装任何程序，只需一个浏览器便可以访问应用。其次由于应用软件与用户pc机进行了隔离，摒弃了由于 pc电脑故障、病毒、硬件损坏等故障所带来的困扰。并且，由于应用程序、数据库也是分离的，对于数据库并发性问题得以解决，同时应用会话的并发性能又有了一定的保障。因此C/S架构在当今已经是相当普及了。
问题1：子系统是个啥？
根据应用功能、实现技术、业务要求，需要把应用系统分而治之，把不同的功能性形成模块化，这就是“子系统”的应用雏形。
问题2：接口是个啥？
接口，一个通讯通道，这是我在客户那里得到的客户认知。在客户眼里，接口就是个通道，负责传输数据用的。这么理解对不对呢？
在有了前两个简单问题的铺垫后，我们下面来闲聊一下逻辑结构。对于划分子系统、定义接口，这些都是典型的逻辑架构设计。对于划分子系统，相信只要是接触过比较大型的系统的程序员来说都会比较容易接受这个概念。在当今倡导可移植、高扩展要求的模块化设计的今天，在一个大型应用下，划分几大类子系统，而又在子系统下根据具体的业务需求去开发出不同的业务功能模块，这一系列下来构成了一个完整的软件架构体系。
对于一个软件系统功能性的把控，更多层面都体现在对于业务的了解。
简单图例，如下：
一个简图呈现出这般，一个良性的生态系统下，对于数据层是必然存在的，我们称之为的后台，oracle、mysql数据库层级。而业务子系统，便是根据不同的业务逻辑而划分出的各大类子系统。一个复杂的平台系统有时会分化出很多业务子系统，而每个子系统下同样会根据实现功能的细化，再衍生出功能模块。这样一个软件系统的雏形就形成了。当然，实际情况到具体的细节上时要比这复杂的多。
这里想说说具体的业务实现，发现又不太合适，而且单一的业务也没有太好的复用性也不太具备典型例子。但是在了解业务的这个过程中，同时发现不仅对之前了解的运行架构有了进一步的了解，也对开发架构，数据如何分布也有了进一步的了解。总之，最后有个结论就是需要学习的地方还有太多，这些事、这些知识，慢慢来吧。
在前行的路上，扩展视野、丰富锻炼、学会宏观的思考问题，这才是成长最大的馈赠。
——深蓝
*******************************************蓝的成长记系列_20150820*************************************
原创作品，出自 “深蓝的blog” 博客，欢迎转载，转载时请务必注明出处（http://blog.csdn.net/huangyanlong）。
蓝的成长记——追逐DBA（2）：安装！安装！久违的记忆，引起我对DBA的重新认知
蓝的成长记——追逐DBA（3）：古董上操作，数据导入导出成了问题
蓝的成长记——追逐DBA（4）：追忆少年情愁，再探oracle安装（Linux下10g、11g）
蓝的成长记——追逐DBA（5）：不谈技术谈业务，恼人的应用系统
蓝的成长记——追逐DBA（8）：重拾SP报告，回忆oracle的STATSPACK实验
蓝的成长记——追逐DBA（9）：国庆渐去，追逐DBA，新规划，新启程
蓝的成长记——追逐DBA（10）：飞刀防身，熟络而非专长：摆弄中间件Websphere
蓝的成长记——追逐DBA（11）：回家后的安逸，晕晕乎乎醒了过来
蓝的成长记——追逐DBA（13）：协调硬件厂商，六个故事：所见所感的“服务器、存储、交换机......”
蓝的成长记——追逐DBA（14）：难忘的“云”端，起步的hadoop部署
蓝的成长记——追逐DBA（15）：以为FTP很“简单”，谁成想一波三折
蓝的成长记——追逐DBA（17）：是分享，还是消费，在后IOE时代学会成长
蓝的成长记——追逐DBA（18）：小机上WAS集群故障，由一次更换IP引起
蓝的成长记——追逐DBA（19）：路上的插曲：触碰“框架”与“软件系统”
******************************************************************************************************************
********************************************足球与oracle系列_20150528***********************************
原创作品，出自 “深蓝的blog” 博客，欢迎转载，转载时请务必注明出处（http://blog.csdn.net/huangyanlong）。
足球与oracle系列（1）：32路诸侯点兵，oracle32进程联盟 之A组巴西SMON进程的大局观
足球与oracle系列（2）：巴西揭幕战预演，oracle体系结构杂谈
足球与oracle系列（3）：oracle进程排名，世界杯次回合即将战罢！
足球与oracle系列（4）：从巴西惨败于德国，想到，差异的RAC拓扑对比！
足球与oracle系列（5）：fifa14游戏缺失的directX库类比于oracle的rpm包！
足球与oracle系列（6）：伴随建库的亚洲杯——加油中国队
******************************************************************************************************************
版权声明：本文为博主原创文章，未经博主允许不得转载。
蓝的成长记——追逐DBA（19）：路上的插曲：触碰“框架”与“软件系统”
原文地址：http://blog.csdn.net/huangyanlong/article/details/47802553
