《河北省重大技术需求征集系统的可用与可修改》

《河北省重大技术需求征集系统的可用与可修改》

对于上学期编写的河北省重大技术需求征集系统的可用与可修改性，在学完软件的质量属性分析后有了一个初步的认识。首先我所自行开发的河北省重大技术需求征集系统的可用性非常的低，最多只能满足不超过五个用户的同时在线使用，所以说可用性非常的低；再说可修改性，因为开发的系统的模块化非常的低，又没有框架作为支撑，所以可修改性也非常的低。接下来说一下再阅读完《大型网站技术架构：核心原理与案例分析》这本书的五六七章之后再对开发的系统进行更加详细的分析。

  首先我们要明白可用性是描述网站可有效访问的特性，也是最牵动人们神经的一个质量属性。中所周至开发低耦合系统是软件设计的终极目标，所以软件的可修改性也就成为了软件属性评价的一个必不可少的属性。

对于第五章的网站的高可用架构

5.1 网站可用性的度量和考核

5.1 网站可用性度量 ，qq可用性4个9，即99.99%，一年<=53分钟不可用 ，2个9是基本可用，一年<=88小时 ，3个9是较高可用，一年<=9小时 ，5个9是极高可用，一年<=5分钟。

5.2 高可用的网站架构

网站高可用的架构设计的目的是保证服务器硬件故障时服务依然可用，数据依然可以被正常访问 
手段是数据和服务冗余备份以及实效转移

应用层：负载均衡设备通过心跳检测，发现服务器不可用则从集群列表中移除 
服务层：分布式服务调用框架会在应用层客户端程序中实现软件负载均衡，并通过服务注册中心进行心跳检测，发现服务不可用立即通知客户端程序修改访问列表 
数据层：在数据写入时就冗余备份，发现数据服务器宕机，则切至备份服务器

5.3 高可用的应用

5.3.1 通过负载均衡进行无状态服务的失效转移(应用逻辑层)

5.3.2 应用服务器集群的session管理 
1.session复制 
服务器之间session相互备份，仅适用于小型的网站，不适用于大型网站，当集群较大并在线人数多的时候，将会出现内存不够存放session的情况 
2.session绑定 
通过负载均衡的源地址通过hash(或者cookie信息)，将同一ip的请求总分发到一台服务器上，但这不符合高可用的需求，一旦宕机则session就不存在了。 
3.利用cookie记录session 
cookie简单易用，可用性高，支持应用服务器的线性伸缩，而大部分需要记录在session的信息比较少时可使用，缺点是受cookie大小限制，每次请求都要传cookie，影响性能，用户要是关闭了cookie则访问会不正常，并且存在一定的安全问题。 
4.session服务器 
使用session服务器，独立部署session服务，达到共享session的效果，一般做法是利用分布式缓存、数据库等，记录session。（memcache记录session）

5.4 高可用的服务

1.分级管理2.超时设置3.异步调用4.服务降级 
5.幂等性设计 
定义：调用一次或者多次产生一样的结果 防止明明请求成功了，由于网络故障没收到响应导致进行重试。(尤其付款时候)

5.5 高可用的数据

5.5.1 CAP原理 
1.数据持久性：写入时写到持久性存储，进行备份，并放在不同的物理存储设备上 
2.数据可访问性：用户无感知情况下，进行数据服务器的切换，切换数据存储设备 
3.数据一致性 
5.5.2 数据备份 
1.数据冷备 
定期将数据备份到某种存储介质中。 据需要比较长的时间 
2.数据热备 
5.5.3 实效转移 
1.实效确认：心跳检测、应用程序访问失败报告 
2.访问转移：重现计算访问路由 
3.数据恢复：

5.7.2监控管理 
1.系统报警 
2.失效转移 
3.自动优雅降级：为了应付突然爆发的访问高峰，主动关闭部分功能

第六章 永无止境:网站的伸缩性架构

所谓的网站伸缩性指的是不需要改变网站的软硬件设计，仅仅通过改变部署的服务器数据就可以扩大活着缩小网站的服务处理能力。

6.1 网站架构的伸缩性

伸缩性分两类：一类是根据功能进行物理分离实现伸缩性，一类是单一功能通过集群实现伸缩性。前者是不同的服务器部署不同服务，提供不同功能；后者是集群内的多台服务器部署相同的服务，提供相同功能。

6.2 应用服务器集群的伸缩性设计

应用服务器首先是无状态的。不保存上下文。主要通过负载均衡进行伸缩性的设计

6.3 分布式缓存集群的伸缩性设计

Memcached分布式缓存集群的访问模型 
通过路由算法从服务器列表中计算出对应的memcache服务器，然后进行连接操作。

Memcached分布式缓存集群的伸缩性挑战 
通过hash对总服务器数目取余的方法来决定选择哪一台服务器。 

6.4 数据存储服务器集群的伸缩性设计

7.1 构建可扩展的网站架构

7.2 利用分布式消息队列降低系统藕合度

7.2.1 事件架构驱动 
通过在低耦合的模块之间传输事件消息，以保持模块的松散耦合，并借助事件消息的通信完成模块间的合作。

7.2.2 分布式消息队列 
伸缩性方面，可以通过加服务器的手段，来对新的业务单独起一个队列进行消费。 
可用性方向，当消息队列太多的时候，直至内存满了，则会讲数据写入磁盘，当处理完后，在从磁盘取出继续处理（redis queu）

7.3利用分布式服务打造可服用的业务平台

 纵向拆分：将一个大应用拆分成多个小应用，如果新增业务较为独立，则直接设计部署一个独立的web系统

 横向拆分：将复用的业务独立拆分出来，独立部署成分布式服务，新增业务只需要调用这些分布式服务，不需要依赖具体代码块。

7.3.1 Web Service与企业级分布式服务

7.3.2 大型网站分布式服务的需求与特点 
1.负载均衡 
2.实效转移 
3.高效的远程通信 
4.整合异构系统 
5.对应用最少侵入 
6.版本管理 
7.实时监控

7.3.3 分布式服务框架设计 
阿里巴巴的Dubbo

7.4 可扩展的数据结构

7.5 利用开发平台建设网站生态圈

 1.API接口：开放平台暴露给开发者的接口，其形式可以是RESTful/WebService/RPC

 2.协议转换：将各种api输入转换成内部服务可以识别的形式，并将内部服务的返回封装成api的格式

 3.安全：身份识别、权限控制、访问带宽限制。

 4.审计：记录第三方的访问情况，并进行监控和计费。

 5.路由：将各种访问映射到具体的服务

 6.流程：隐藏服务细节，提供统一服务接口

对于我所开发的《河北省重大技术需求征集系统》尚且只能完成数据的提交网页的访问，粗略的使用，尚且达不到可用性与可修改性的分析。