来自软考论文
改进web服务器性能的技术
[摘要]
一个大中型的智慧连锁餐厅管理系统涉及到许多方面的技术与方案，本文着重讨论与Web服务器性能有关的一些内容。（扣题）
本人有幸作为项目负责人之一参与了某智慧连锁餐厅管理系统的设计和基于Web应用软件的开发工作。（我的职责）由于客户关顾餐厅的时间具有集中性，以及数据分析计算和推荐的实时性需要，对Web服务器性能有着较高的要求。（过渡）
（阐述自己的方案） 结合实际工程经验，本文将从硬件实现手段(缓存服务器、均衡负载设备、web双机镜像、CPU和网卡的提升、网络带宽扩充)和软件实现手段(三层C/s软件结构设计、应用程序部署)等两个大方面论述如何提高Web服务器的性能，以便使用户能够更快捷、高效、安全地使用应用系统。（意义）
[正文]
随着Intranet信息技术的发展，连锁餐厅为了更好地发挥其餐厅管理、用户分析和O2O线下下单服务的职能，连锁餐厅的数字信息化工程也势在必行。某连锁餐厅为了尽快地步入国内领先智慧餐厅的行列，已经启动了一部分的餐厅智能工程.（背景）
该餐厅智能工程主要包括对外信息Web发布系统，交互式下单服务，后台餐厅管理系统、实时数据采集分析系统等。（体系概述）本人有幸作为项目负责人之一，参与了整个数字化信息系统的总体设计，并参与了基于Web的一些应用，如对外信息发布系统、交互式下单服务、后台餐厅管理系统的开发。（我的职责）
某集团连锁餐厅管理系统从网络环境上讲，主要划分为多个网段（网段）: (一) Internet接入部分，采用2M的DDN专线; (二)公共网段，主要包括前台发布数据库服务器、Web服务器、E- mail/FTP /DNS服务器、SAN网络区域存储设备; (三)是内部局域网，包括内网Web服务器、后台系统数据库服务器、OA服务器等。/（网络安全）由于制定了严格的网络级和应用级访问权限，通过具有三层交换能力的高性能交换机(局域网)和安全授权认证系统等，有效地控制了访问权限，确保了数据的安全性和完整性。/（网络运行操作系统）考虑到经费和人员素质及今后的维护管理运营等方面，操作系统采用LINUX平台，（网络运行服务器）服务器选用DELL高端的系列，(数据库)数据库采用IBM的DB2.（网速）主干网为千兆快速交换式以太网，局城网百兆到桌面。
（应用分类）在该网络环境下应用主要分为三大部分: (一)对外Web发布系统、对外餐厅下单系统; (二)后台餐厅管理系统，(三) 数据分析系统。（应用使用）由于绝大部分应用采用Browser /Server方式结构，最终用户在本地只需安装Web浏览器，在后台数据库服务器的支持下通过网页方式请求和访问各类应用服务。（性能背景）另外，由于客户关顾餐厅的时间具有集中性，以及数据分析计算和推荐的实时性需要，对Web服务器性能有着较高的要求。
（引述）通过不断地试验和实践，我们发现从以下几个方面可以相对有效地提升Web服务器性能:
- （具体方案）缓存服务器和均衡负载设备使用可以缓解访问瓶颈，提高网络带宽、实现均衡负载。
（细说）缓存服务器也称为cache服务器，可以存储静态的内容如网页、多媒体资源和会议实况(已压缩的、有一-定格式要求的)等。（cache服务器位置）cache 服务器通常放到防火墙之外，外网Web服务器之前，（好处）因此，用户点击网页不再直接访问网站Web服务器，而是访问cache服务器，并将用户的请求和应用服务器应答的内容写入缓存服务器中，从而为后续用户的访问提供更快的响应。
（好处）由于cache 服务器具有多个CPU和高速大容量I/0 通道，独立的0S，因此能大大緩解Internet访问瓶颈，而且也具有一定的抗黑客攻击的能力。
（实际）目前某连锁餐厅采用这种方式，把大数据量的静态图片、多媒体资源等都事先置放在cache服务器中，即使现今接入带宽不太充足，以上应用的效果仍能让用户满意。
另外一种方式采用均衡负载设备或Web双机镜像。这种方式通过负载均衡的方法达到Web访问性能最优。(对比)/Web 双机镜像是较早以前流行的方式，（优缺点）虽能使系统可靠性提升，但由于双机总是在互相询问对方状态，将会影响一定的访问性能。（性能优点）均衡负载设备是独立于Web服务器的硬件，它和Web服务器及网站中其他服务器接在同一交换机上，通过负载调度程序为各个服务器分配工作量，从而，能达到充分利用资源，提高访问性能的目的。（实际情况）只是由于某集团连锁餐厅目前对外发布资源相对较少，只有用了三台Web服务器，因此目前的均衡负载设备作用还不显著。
（双机热备特指基于高可用系统中的两台服务器的热备（或高可用），双机高可用按工作中的切换方式分为：主-备方式（Active-Standby方式）和双主机方式（Active-Active方式），主-备方式即指的是一台服务器处于某种业务的激活状态（即Active状态），另一台服务器处于该业务的备用状态（即Standby状态)。当其中运行着的一台服务器出现故障无法启动时，另一台备份服务器会迅速的自动启动并运行（一般为数分钟左右），从而保证整个网络系统的正常运行！双机热备的工作机制实际上是 为整个网络系统的中心服务器提供了一种故障自动恢复能力。）
(2)（具体方案）从Web服务器的配置来看，Web服务器自身CPU个数及速度、网卡数量、Web服务器与防火墙的位置关系等，都会影响到Web服务器的性能。
（细说）从Web服务器硬件本身来讲，CPU 个数的增加、网卡个数的增加、I/0 信道的扩展无疑可以直接地提高Web服务器性能。此外，（web服务器位置关系）由于千兆口的防火墙目前较少且费用较高，如果把Web服务器放置防火墙之后，一定会大大影响Internet访问性能。（实际）某集团连锁餐厅采用IDS (入侵侦测)+Web服务器( 服务器防火墙，较低端，不会影响流量) +应用服务器+数据库服务器(防火墙，高端)（实质在说三层c/s架构），（结果）分层次的安全模式，既保证了系统的安全性，又提升了网络访问性能。
（补充）另外，某连锁餐厅还采用了SAN 网络区域存储来提高服务器访问速度。
(3)（具体方案）三层C/s软件结构设计和应用程序的适当部署也会提高Web服务器的性能。
（细说）将业务逻辑 (后端)、通用访问接口（前端）与数据（数据库）等相互分离、分别置放于Web服务器、应用服务、数据库服务器上，通过程序功能和逻辑的合理部署，也能大大改进Web服务器性能。
（详细方案）一般的原则是，Web服务器只需接受Internt http访问请求，使Web只有最少的任务，把实际处理交给各个应用服务器处理,然后返回结果给浏览器.（实际）某集团连锁餐厅采用这种方式专门开发了后台管理系统应用服务器和在线下单应用服务器等，达到了良好的应用效果。
（总结）事实上，Web服务器的性能提升还存在很多手段和方法，比如CPU与存储之间关系，Wet 交换机等等，有待于我们进一步的实践、分析和讨论。
论软件的可维护性设计
注意如果题目说论软件或者web，那么就要更名，软件（综合智慧餐厅软件），web(综合智慧餐厅系统)
摘要:
(维护在开发中考虑的必要性)（地位）随着软件大型化，复杂化的发展，软件维护所耗费的资源越来越多，软件可维护性设计日益得到重视。我单位近几年开发综合业务智慧餐厅管理系统，用户对智慧餐厅管理系统的可维护性要求很高。我参加了该项目并负责软件的维护性设计工作。根据当前工作中在维护性设计中的不足。通过在各个软件开发阶段注重软件可维护性的应用，规范文档，使用CASE工具管理软件版本和成立软件可维护性设计小组等方面，为软件的可维护性设计提供了帮助，并最终开发出具有良好可维护性的交换机软件。但是由于初次实施这方面的工作，大家思想上认识不够，许多操作不习惯，并且单位里不具备专用的测试软件和其它CASE工具，在-定程度上制约了软件可维护性的实施。
正文:
（项目概述）经过一系列的需求分析、设计、编码和测试之后，软件正式交付用户使用。至此，软件变进入维护期。（地位）软件维护的工作量特别大，随着时间的推移，软件维护对开发商带来的成本压力也越来越大。（过渡）许多软件开发商要把70%的工作量用在维护已有的软件上，平均来说，大型软件的维护成本是开发成本的4倍左右。（结论）因此，在开发软件时，就应该考虑到可维护性问题，进行软件的可维护性设计。
（我的职责）2014年底，我单位开始为某集团开发综合智慧餐厅软件。该综合智慧餐厅软件支持多种业务应用，包括数据分析、日常管理和分布式等;由于软件业务的复杂性，用户对该软件提出了很高的要求，并且提出要求产品交付使用之后，我单位要有很好的服务支持，鉴于将来用户量的上升，软件的可维护性设计被提上日程。我有幸参加了该项目，并负责软件的维护性设计工作。
（实际）在以前的课题中，也曾提到过要进行软件的可维护性设计，但在真正实施过程中，还存在诸多问题，主要表现在:
(1)（过程）在软件开发过程中对可维护性设计考虑欠缺，导致软件设计从根本.上就忽视了可维护性的重要性。
(2)（文档）软件设计文档不规范，内容不一致.在维护阶段出现问题，根据文档不易得到有帮助的信息，难以定位错误的类型和根源。
（方案概述）在本系统的设计过程中，我们通过注重软件可维护性的开发过程，规范文档，使用CASE工具管理软件版本和成立软件可维护性设计小组等方面进行软件的可维护性设计，最终开发出具有良好可维护性的交换机软件。
一、注重可维护性的开发过程
在整个综合智慧餐厅软件的开发过程中，从软件易于理解、易于测试、易于修改的角度出发，提高软件的可维护性。
（需求分析）在需求分析阶段，和用户进行充分的交流和协商，对将来要改进的和可能要修改的部分进行明确。（原因）由于该智慧餐厅管理系统所涉及的业务种类厂泛，（->）并且综合了数据分析、系统管理和分布式等多种技术，任何一种技术实现的功能不完善或者扩展性不好，都不会让用户满意。（方法补充）但是，另一方面，(原因)又考虑到用户需求和功能需求并非容易获取，（方法）所以通过和用户定期交流，举办各种形式的讨论等方式尽可能了解当前的需求和以后需要扩展的需求信息，由专人整理记录这些信息，作为以后的跟踪内容。即使在其它设计阶段对需求的临时变动，也要在这个记录中体现。
（设计）（解决方案）在设计阶段，智慧餐厅管理系统被划分为不同模块进行设计，并遵循“高内聚、低耦合”的设计原则，（原因）这些工作便于将来软件维护工作的进行。（方法补充）同时也已考虑到，对可能要扩展的地方，预留出充足接口。（实际）在一些模块中，根据功能，尽可能使用面向对象的设计方法，以便维护时的修改和升級。
（编码）在编码阶段，我和小组成员制定了统--的编码规范，（->）经过半天的培训，强化编码人员对注释的使用，|并强调要保证注释的质量，（->）对有可能出现误解的地方，注释的要详细。(->)并且，每个文件都要注明编写者，生产日期和版本号.
（测试）（概述）在测试阶段，测试组成员已经负责进行测试，我们小组这时的工作是根据测试报告，对照测试大纲和用例设计，对当前的测试进行总结，（实际）比如，何种测试用例发现何种错误，最常见的错误，如何从测试结果判断是哪种错误，该错误所在的模块是什么。在相关人员修改错误时，记录排错时的思路和过程。（补充）特别是，根据这些总结，我们编写了“智慧餐厅管理系统故障解析”，这篇总结在后来的维护阶段被证明是最受欢迎的文档之一。
（维护）在维护阶段，制定严格的管理要求。每一次维护工作之后，都要按照配置关联，同步更新维护有关的系统文档和用户文档，包括维护需求、源代码、注释、设计文档、测试文档和用户使用手册等，保证系统的一一致性。维护中所进行的修改要专人记录，生成“智慧餐厅管理系统维护更新”文档，做为内部文件存档。同时把一些内容扩充到“智慧餐厅管理系统故障解析”中。在用户使用时，做好用户的培训工作，初期由专人和用户一起操作智慧餐厅管理系统，直到能熟练操作，以免用户使用智慧餐厅管理系统时产生不满。
二、规范文档
交换机交付用户使用之后，除了在培训时所了解的内容之外，为了让用户对智慧餐厅管理系统能够更好的理解和使用，向用户提供了多种随机文档，包括功能说明，安装文档，用户使用手册，参考手册，管理员指南等。在文档的编写过程之前，我们编写了“智慧餐厅管理系统文档编写规范”，对文档格式和一些必要内容进行了规范，保证各文档的风格一致，内容一致。对于一些用户使用中容易出错的地方，比如配置某种功能时，在用户使用手册示例说明。在具体编写文档时，根据设计人员的反馈信息，也及时调整了文档编写规范。
在设计开发过程中，对某个问题进行修改，或者功能增删，要充分考虑到问题所涉及的不同文档，保证前后文档在该问题的一致性.对于所修改的部分，要填写“更改单”，需要写明更改人，更改理由，更改所影响的程序和文档，更改日期，批准人。采用CASE工具在这一方面也起到“了事半功倍的作用。
三、使用CASE工具管理软件版本
在软件的设计编码过程中，尤其是在调试阶段，会不断的生成新的程序版本。为了有效的管理版本问题，采用Ration公司的ClearCase工具，由专人负责进行管理，从而保证软件版本的一-致性。
四、成立软件可维护性设计小组
为了有效的对软件可维护性设计进行管理，成立了软件可维护性设计小组。我担任小组组长，明确了维护性设计的工作内容和各人的责任，针对不同的模块，又确定四个责任人。在运作过程中，组长对软件开发阶段所需进行的工作进行协调，各负责人对维护性设计所涉及的变动控制进行维护.
因为交换机软件的各个模块开发时间有穿插，因此，对开发过程中出现的一些问题，包括技术方面和管理方面的问题，我们都及时进行了记录，对后面开发的软件模块进行指导，避免了同样问题的再次发生。现在这份文档已经成为单位新课题启动时的“必修”文档。
按照_上面的思路，经过两年多的工作，我们已完成了交换机软件的开发，新的软件运行良好，交付用户后，用户很满意，受到了业务部门和技术部1 ]高层的赞许。尤其是我们所总结的“智慧餐厅管理系统故障解析”和“智慧餐厅管理系统文档编写规范”等文档，对单位其它课题也起到了很好的指导和规范作用。并且，在提高软件可维护性的同时，也提高了软件产品的质量，我自己的开发管理水平也得到了很大的提升。单位的高层领导对我们制定的规范和做法也表示认可，正式在其它课题中推广。
然而，由于初次在整个软件开发过程中进行可维护性设计，还有许多要改进的地方。许多情况下，现有的可维护性设计措施理论性太强，具体实施时可参考的依据少，比如我们测试小组如何更好的与各课题开发组间进行协调工作，感觉还是有不尽人意的地方。在测试阶段，单位条件所限，没有采用专业的测试软件进行测试，主要靠人工根据经验生成测试用例，测试力度不够，隐含的问题较多，这也不利于今后的维护工作。
软件可维护性设计是一个长期的工作过程,我希望今后能够不断的充实自己在这方面的知识，提供整体能力，为单位软件可维护性设计方面提供新的、好的思路。
论软件三层结构的设计
摘要
随着市场的建立和发展，卫生行业面临了很多问题，一些制约 卫生事业发展的矛盾和问题日益显现，因此，国家卫生部要求各医院采用信息化管理。前不久，我所在的部]承担了了一个医院管理系统的设计和开发，医院希望以此来转变医院现有的运行机制，提高服务质量。该系统除了目前常见的结费系统、电子病历外，还包括门诊医生工作站、住院医生工作站、护士工作站等分系统。考虑到需要通过Intranet实现功能，并有部分的Internet功能，本项目平台最后采用了Java平台。我在项目中主要负责项目的的前期规划，即选择合适的开发方案，并建立部分的数据流，在系统实施过程中推动其顺利前进。此系统开发成功后投入运行，获得医院相关工作人员的好评。
正文
前不久，我所在的部门承担了了一个医院管理系统的设计和开发，医院希望以此来转变医院现有的运行机制，提高服务质量。客户是一个市级医院， 医院很早就开始从事信息化管理，但主要是针对结费这一块，后来，对其进行了改进，加入对病人电子病历的管理和采集,这样当病人二次就诊时，可以很容易地得到病人的既往病史。但随着系统的运行，院方希望对现有系统进行改进，为了更好得为病人服务，医院考虑加入一些其它的分系统，比如门诊医生工作站、住院医生工作站和护士工作站等等.因此我所在的部门承接了该HIS的开发，开发的成果是一一个典型的Java技术在Intranet,上的应用。
在开发前期，首先要设计出详细的系统功能规范，这一部分所花费的时间很少，因为卫生部在2002年曾经颁发了一个有关医院管理系统功能规范的通知，我们参考了该规范，很快确定了各分系统以及每个分系统的的基本功能。但在选择合适的系统平台，上有一番讨论，考虑到医院原有系统在某些地方运行良好，是否有必要将原有系统淘汰重新设计，另外新的分系统到底采用何种平台结构也是需要考虑的问题。
医院原有的结费系统和电子病历系统数据流向范围比较固定，主要集中在交费处和挂号处，一旦引入了新的系统，必然要将数据流向医院的各个部门。医院的Intr anet已经实施，因此首先考虑采用B/S架构体系，旧系统的数据模型尽可能保留。在系统的软件平台上，我们考虑使用Java平台，可以让数据在整个系统安全、有效地流动;另外现在也有很多的HIS系统可供我们参考，虽然往往是单机版的系统，但其中的数据模型有很好的参考价值。医院的现有网络系统和操作系统多种多样，这就要求我们选择的软件平台必须具有开放性、平台无关性。而在不同的系统上安装相应的Java客户端虚拟机并不困难，最后，在项目组的讨论和征求客户意见下，项目组采用了此方案。
（总述解决方案）在项目中，我们这样设计Java架构系统，将系统分为三层:
(1)表示层采用Jsp实现页面输出，这也是用户直接访问层，表示层接受来自网络浏览器的HTTP请求，然后返回给客户端浏览器可以显示的HIL页面;
(2)中间件层用Java实现对数据库的访问，考虑到数据的分布特点，我们使用了数据库连接池技术，
(3)数据库层用SQLServer 实现数据库的管理和存储过程。
(表现层)(概述)JSP以其执行的高效性和使用的方便性，已成为近年来大家首选的Internet开发技术，JSP是一种页面开发技术，它以Java为其服务器端语言，结合JavaScript作为其客户端语言，能方便地实现页面的表示。（原因/优点）选择Jsp作为前台语言，是考虑到它的平台无关性，能够兼容其他的操作系统。利用Jsp可以将HTML文件很方便地发送到客户端，同时也可以支持一些非HTML格式的文档发送。（实际）我们在网站的用户层页面设计中，广泛地参考了现有的一些成功案例，在节约设计和开发的费用的同时也得到了用户的认可。（用户界面定制）比起单纯的Servlet技术，Jsp在页面元素上也更为丰富，在这里，我们为今后客户页面定制做了部分尝试，设计了一个比较简单的模块，用户可以通过选择控件来动态生成页面提供打印，当然在这部分我们设计中，可提供的数据库字段是固定有限的，灵活性没有很好体现。
（中间件层）（问题、背景）我们大量工作主要放在中间件层，(问题引出)由于系统中的大量数据分析计算是主要部分,因此数据库的负载成为一个不得不考虑的问题。（概述解决）综合考虑，我们决定采用数据连接池技术，(原因)因为基本上每个用户都对应一个客户终端，无论是餐厅菜品的查讯或录入，或者大量订单的处理，都涉及到对数据库的频繁读写，服务器对于数据连接的频繁打开和关闭必然导致性能下降。/(详细解决1)一方面，我们预先考虑数据库的连接量，在系统初始阶段建立相应的存储空间，当数据库连接打开和关闭时都对该连接池进行处理;/(详细解决2-缓存)另一面，我们也使用了高速缓存技术，对某些较为固定的SQL查讯结果，例如菜品列表、菜品排行等，将结果采用缓存存储，以加快对数据库的访问，降低了服务器端的负载，提高性能。（电子签名）值得一提的是，为了尽可能得避免纠纷，某集团要求采用签名制度，我们设计了电子签名，采用加密算法保证各环节产生数据的有关人员不能抵赖。
（数据库层）数据库层我们选择了SQLServer,（原因）程序员比较熟悉此平台的开发和设计。（数据库分析流程）在前期，我们到某集团连锁餐厅做了大量的走访工作，了解整个数据流，同时广泛参考现有的系统，虽然对连锁餐厅行业不是很熟悉，但数据层开发遇到的问题的并不是很大。（数据库设计）在概要设计阶段，我们使用了一些计算机辅助开发工具，这也加快了详细设计的进程。比如使用了Sybase 的PowerDesigner工具，在概要设计中规划了E-R 图和各个分系统以及分系统之间的数据流图，然后让工具直接生成后台数据库中的基本表结构，大大提高了开发效率。
（过渡到技术缺点）整个项目实施完成后，集团相关工作人员反映良好，但其中也暴露出了-一些问题，值得改进。
（表现层缺点）首先，用JSP编程时容易导致系统信息的扩散。如果有人恶意攻击服务器，程序执行将出现异常。这时，就会在页面上打印出相应的错误信息。这些信息会暴露出这台服务器的路径信息。这个漏洞往往会被人利用，程序员对此也一头雾水，下一步我们考虑从服务器入手，采用通用的异常说明界面，解决该问题。
（UML建模缺点）其次，(设计)在设计上，可以使用更多的辅助开发工具和建模工具，比如Rational Rose, 可以利用它的代码自动生成功能，来大大提高开发速度;（定制界面）在用户界面定制方面，我们希望通过不断的实践，加强其灵活性，尽可能把可供选择的字段扩大到整个数据库。
（中间件层缺点）最后，大量使用Java技术，势必对服务器的负载过大，在今后的开发中，除了现有的数据库连接池和缓存技术，我们考虑使用更多的数据库脚本来替代部分Java代码，来高速实现逻辑，相较而言，数据库脚本的执行速度较有优势，结合结果缓存，应该对服务器的性能有较大的提高。
上面是我在今后的 系统设计和开发中需要注意和加以改进的地方，也是我今后应该努力的方向。
论分布式数据库的设计与实现
摘要：
本文讨论某高校管理信息系统中分布式数据库的设计与实现。该系统架构设计采用C/S与B/S混合的架构方式。在全局数据与各院系的数据关系中，采用水平分片的方式；在全局数据与各部门之间，以及数据库服务器与Web数据库服务器的数据关系中，采用垂直分片的方式。设计过程中采用了基于视图概念的数据库设计方法。开发过程中在数据集成、测试、分布式数据库部署等方面做了大量的工作。并使用合并复制的方式有效地解决了分布式数据库中数据同步的问题。
正文：
针对某高校管理信息系统的开发，该高校共有三个校区，总校区和两个校区，教务处等校级行政部门在总校区办公，15个院、系分布在两个校区。在工作中它们处理各自的数据，但也需要彼此之间数据的交换和处理，如何处理分散的数据和集中的管理是一个难题。学校信息系统中复杂而分散的数据信息之间的交换、相互转换和共享等问题是系统开发要解决的关键性问题，分布式数据库系统技术为解决这个问题提供了可能。
1、系统的架构设计
采用分布式的B/S混合的架构方式。各院系、部（室）通过局域网直接访问数据库服务器，软件采用C/S架构；其它师生员工通过Internet访问Web服务器，通过Web服务器再访问数据库服务器，软件采用B/S架构。学校各部门之间工作时数据交互性较强，采用C/S架构可以使查询和修改的响应速度快；其它师生员工不直接访问数据库服务器，能保证学校数据库的相对安全。
2、数据的分布
从全局应用的角度出发，将局部数据库自下而上构成分布式数据库系统，各系部存放本机构的数据，全局数据库则存放所有业务数据，并对数据进行完整性和一致性的检查，这种做法虽然有一定的数据冗余，但在不同场地存储同一数据的多个副本，能提高系统的可靠性和可用性，也提高了局部应用的效率，减少了通讯代价。
将关系分片，有利于按用户需求组织数据的分布，根据不同的数据关系采用了不同的分片方式：
（1）在全局数据与各院系的数据关系中，由于各院系的数据是全局数据的子集，采用了水平分片的方式。
（2）在全局数据与教务处、总务处等各部门之间，数据是按照其应用功能来划分的，所以采用了垂直分片的方式。在数据库服务器与Web数据库服务器的数据关系中，情况也是相同，也采用了垂直分片的方式。
3、数据库视图设计
由于系统需要满足来自不同用户的查询需求，如学生查询考试成绩、教师查询考核情况、师生查询图书信息等，因此使用了大量的视图，来满足各方面的查询需要。另一方面这种设计也防止了人为因素造成的数据更改，同时满足了系统安全性的需要。
在进行视图设计时，首先从分析各个应用的数据着手，为每个应用建立各自的视图，然后再把这些视图汇总起来，消除命名冲突和冗余，最后形成整个数据库的概念数据模型。
4、数据集成
各系部的局部数据在录入后，要及时上报，在全局数据库进行汇总。各部门的数据有更新变动时，也要及时上报在全局数据库同步更新。再由全局数据库分发给与数据信息有关的相关部门。如某系学生人数的变化要通知后勤服务部门。人事部门上报教工工作的调动情况要通知财会部门等。数据的交换集中在各系部局部数据库与全局数据库之间，提高了系统集成的可靠性；数据交换的功能在中心数据库与各系部间进行，中心数据库所在的服务器分担大部分数据交换所需的处理工作，可减少各系部之间的数据交换，保证数据的一致性。在数据库到数据库的操作中，通过两阶段递交协议来确保中心数据库和分布在各个系部的数据的一致性、完整性。
5、测试
由于该系统涉及到多个系部，数据共享关系复杂，数据量也较大，因此在测试时使用的是高校系统的真实的数据，从数据的采集、传输、存储、处理和显示等的各个环节，全面测试了数据库的功能，以及数据库的性能和安全性等，根据测试结果和用户意见进行了修改。
6、部署
在数据库选型的问题上，考虑到操作人员对SQL Server数据库比较熟悉，采用SQL Server数据库构造整个数据库平台。各校区都有自己的数据库服务器，而全局数据库服务器只有在总校区才有，不同校区之间的数据通过总校区以复制的形式同步，两个分校区和各系部之间不直接进行数据的复制，这种服务器的分布形式达到了以下两个目的：首先，全局数据库服务器在总校区，保证了整个学校的数据统一。再者，通过后台的数据的同步进程保证了总校区和各部门之间的数据传输，可实现校办总部对下属单位的数据有条件发放，下属单位数据无条件上传总校，为整体数据提供了安全保障。
在分布式数据库设计中遇到的最主要的一个问题就是数据同步的问题。由于全局数据库与各部门的数据交换是双向的，各系部需将更新的数据发送到全局数据库，全局数据库负责整体协调，要向下属单位下发管理信息和与其工作相关的其它部门的更新数据。使用合并复制方式实现数据同步，把全局数据库服务器设置为出版者，各部门数据库服务器设置为订阅者，合并复制监视源数据库中的改变，并同步出版者和订阅者的数据值，其中无论是出版者还是订阅者均可以更新数据。当出版者同订阅者发生冲突时，将出版者设置为高优先级。
7、总结与展望
目前，该系统已经稳定运行一年多的时间，得到了该大学领导和有关人员的好评。但也有需要改进，完善的地方。比如应加强保障系统安全性方面的设计，提高系统的健壮性。应用分布式数据库技术可以有效地解决数据分散和集中管理的矛盾，实现数据的共享和交换。在实际中，分布式应用系统很多是异构的，异构不仅仅是数据库，也包括硬件和操作系统。应用XML和中间件技术实现异构数据库集成是分布式应用的发展趋势。
Docker 是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何流行的 Linux 机器上，也可以实现虚拟化。容器是完全使用沙箱机制，相互之间不会有任何接口
缺点局限性：
1.Docker支持Unix/Linux操作系统，不支持Windows或Mac（即使可以在其上安装，不过也是基于Linux虚拟机的）
2.Docker用于应用程序时是最有用的，但并不包含数据。日志、跟踪和数据库等通常应放在Docker容器外。
（介绍）pxc集群是基于percona数据库和galera中间件一种特殊MYSQL数据库，（对比）pxc集群相比mysql单一数据库或者mysql主从复制数据库的优点：（一）所有节点均可读可写，可以轻松起到HA的作用，任意一台节点宕机都不会影响全局服务。（二）在任意一节点写入都是事务强一致性的，不同于主从复制使用异步复制的方案导致主从数据不一致的情况。（三）某一个节点宕机之后，再重启恢复后会自动的将宕机期间没有写入的数据补充回来。
（总结）所以pxc集群不仅可以实现传统的读写分离功能，更在高可用和强一致性上提供了较强的解决方案，（效果）从而提高了mysql数据库的可靠性，并且部署简单。（结合）通过Haproxy与pxc集群结合实现数据库集群的负载均衡能力，平衡数据库集群的读写工作量，提高了分布式数据库性能和高可用性。
（介绍）分布式缓存由一个服务端实现管理和控制，有多个客户端节点存储数据，可以进一步提高数据的读取速率。（原因）同时根据一致性哈希算法确定数据的存储和读取节点。（好处）一致哈希算法的好处在于节点个数发生变化（减少或增加）时无需重新计算哈希值，保证数据储存或读取时可以正确、快速地找到对应的节点。
（优点）分布式缓存能够（5个优点）高性能地读取数据、动态地扩展缓存节点、自动发现和切换故障节点、自动均衡数据分区，而且能够为使用者提供图形化的管理界面，部署和维护都十分方便。
论软件需求分析方法和工具
摘要
本文通过一个集成电路设计有关的软件项目，讨论了该项目的主要特点和本人所担任的工作，着重讨论了在项目需求分析过程中采用的具体方法和工具以及选用的理由。
由于项目的专业领域的特殊性，分两类不同的需求讨论了需求分析中遇到的问题及解诀方法;在这个过程中给出了对选用的具体工具和方法的效果的描述。接着本文讨论了对使用方法的改进的一些想法以及具体的实现过程。最后提出了我对需求分析的某些看法，强调了与客户沟通的重要性。
(正文]
近年，我一直从事某企业中有关IT项目的开发，有一个系统是用于计算机辅助电路设计的，包括了从上流设计(注:日式说法)到下流设计(注:日式说法)的所有流程，如用于可设计百万1 ]数量级的逻辑|门电路。有关方面把电路中路径的提取、过滤以及表示的某软件开发任务交给我公司，我有幸担任了该部分的需求分析以及设计。
我所设计部分为一单独可启动的软件，主要是解析文件中的连线路径，以列表视图和用直方图等把它们显示出来，还可以执行诸如查找与过滤等功能。
（需求说明）（客户）委托方对此提供了很初步的需求说明，把一些基本功能及性能要求描述了一下。(职责描述)我在需求分析时的工作主要有两点:第一，对该软件的界面等详细需求要自己重新进行分析提取。第二，对于已提供的功能要求需要深化和细化，以形成真正完整的需求分析文档。
（方案计划）在接到需求分析任务后，我分析了一下所要完成的工作。发现由于是专用领域的软件，对专业领域要求相当高，所以准备把此项目分成两部分:
(1)（界面）界面所受专业领域影响几乎没有，但由于全部没有任何要求，反而会感到风险和改动可能是最大的。
(2)（功能）功能方面由于委托方的许多功能都可以调用相应模块来得到，并且已有了相应的书面的简单需求，相应来说只是完成深化。（概述俩者方案）对界面，我采用了部分RUP的思想迭代与渐进。而对功能需求采取了分层细化，每细化一层就要求委托方确认、修改和补充。
（需求1分析-确定元素）首先把风险较大的部分完成，这是现代软件开发的基本常识。我选择先进行界面的需求分析。（界面方法概述）第一步是根据功能描述抽取出逻辑模型，并使逻辑模型与界面元素及功能一一对应，大体上决定了界面应有的功能，然后根据该界面功能描述，确定具体的控件，（->）(实际)这时，我参考了委托方已初步完成的主窗口的界面布局及控件的使用规律，然后根据需要完成的功能从Qt(由于要支持Windows和Unix双平台，所以控件库采用Qt)的类库中选择相应的控件。（方法详述-逻辑模型）在提取和抽象逻辑模型时，我采用了Rose 2000 中的用例图，即以USE-CASE图来描述与外部的关系。（原因）之所以采用Rose,我是基于以下的原因:第一，在已开发的部分中，委托方统一要求我们使用Rose进行类和顺序图等的设计和代码生成。第二，Rose 提供了标准的图来描述系统与外部的关系，在全球范围已是一种标准结构。第三，使用上的方便性。（成果）我用Rose的USE-CASE图，理清了我们的软件窗口(日式说法，即:沟通人员)与委托方主窗口(日式说法，,同_上)以及外部角色(操作者)之间的相互关系。
（需求1分析-文档优化）（问题）在确定了界面元素后，考虑到文档的可理解性不是很强，（工具）我采用Visio 2000把界面的外观绘制出来，写上了基本的控件作用，随后送给委托方评审，幸运的是除了几个小功能的修改，委托方基本批准了我的方案。
（需求1分析-控件状态）下面的工作是为控件的行为及状态变化制定相应的状态迁移图，我选用的工具仍是Rose, 我用了状态图和时序图，把重要的控件状态变化及相应顺序进行了描述，随后的几天把相应的DOC文档建好写明，基本上界面设计就完成了.
（需求2分析-功能性需求）（问题）下面的需求是针对功能需求的。虽然委托方技术部]有初步的需求文档，但由于领域的专门化不对，我不清楚其中复杂的路径提取关系及较深入的专业术语，一直有一种举步维艰的感觉。（方法）只能采用分层细化的原则，从最初的几条深入一层变成十几条。(好处)这样的话，不会一下子碰到太深的专业问题，可以循序渐进从委托方与文献的解答中不断学习，深化自己对专业领域的了解，这样在设计中自己始终是层层推进的，不至于碰到无法逾越的专业障碍。
（总结）（问题）在这一阶段的开发中，由于一直是与自己不熟悉的专业领域打交道，所以我觉得一些辅助设计工具似乎无法发挥应有的功能。（方法1-Email）在这期间，对我帮助最大的应是公司的E-Mail系统，所有不清楚的问题的提出，以及对问题的解答都通过它进行周转。（补充）换句话说，在需求分析阶段，它起到了一个与客户的交流沟通和客户需求的提取作用。(总结）所以，我认为在这一阶段，E-Mail系统是对我帮助最大的工具，（方法2-Excel）其次是Excel, 我用它建立了问题跟踪图表，对每一一个提出的问题，均需要记录上去，把问题结果(可分为已清楚、仍不太清楚、不清楚、尚未回答)均记录下来，根据这些表，我可以很好地了解自己工作中的核心问题，并有了解它的方向，提高了工作效率。
（需求1+需求2分析-结束）每进行一层的细化，我都把结果交付委托方审核，由他们决定何时能终止细化，大约在八层细化后，对方认为已达到了效果，确认可以结束。至此，分析工作全部完成，项目的需求分析基本成功了。
（成功原因）在这次需求分析中，我认为取得成功的原因主要是方法和工具选择得正确。在界面设计中采用了流行的辅助工具，对需求及逻辑模型的建立提供很大的帮助，可以更方便帮助自己理清思路。选用了迭代法，把一些错误的影响在功能分析和界面分析的不断迭代过程中加以改正。在后期，以功能需求为主时，我主要依赖的是沟通工具和表格工具，这也说明辅助工具不是万能的，需求分析的关键之关键，应是与客户的交流与沟通。
（项目感受）通过这次案例，我认为在软件的需求分析工作中，方法的重要性应远超过工具的使用，(->)（风险处理）应当首先确定分析中的风险，把风险分类，用不同的方法去解决各类风险，（工具选择的感受）而工具的选择不仅是要看影响力和名气，而是要真正为我所用，应把握其精髓，即是此工具到底可以对开发有什么帮助，而不是仅限于如何使用。（工具类型的感受）我认为在需求分析中工具的作用不外乎两个:一是实际系统与环境模型等的抽象工具，二是需求表达工具。第一类的代表是Rose,第二类的代表是Word, IPS, Visio等，在这次项目中由于地理上的限制还用到了沟通工具，Web浏览与E-Mail服务系统。
最后我还是总结一下，在需求分析中工具方法都只是辅助项目成功的因素，真正的决定因素还是一“ 与客户的沟通”。