架构核心五要素

标签： 架构 核心 | 发表时间：2014-04-17 04:34 | 作者：liudong1105
出处：http://blog.csdn.net

架构设计中要考虑的核心五要素；
性能、可用性、扩展性、伸缩性、安全性

性能

性能的测试指标

  • 响应时间
    应用执行一个操作需要的时间，包括从发出请求开始到收到最后响应数据所需要的时间。响应时间是系统最重要的性能指标，直观地反映了系统的“快慢”。下表列出了一些常用的系统操作需要的响应时间。
    image

  • 并发数
    系统能够同时处理请求的数目

  • 吞吐量
    单位时间内系统处理的请求数量;
    如：TPS、QPS（每秒查询数）

随着并发数的增大，吞吐量随着增大；
超过阈值后，并发数继续增大，吞吐量下降，直到吞吐量降为0，网站宕机；

理解上述3个指标：类比高速公路行车
吞吐量就是每天通过的车辆数
并发数是正在行驶的车辆
响应时间是车速

性能测试方法

  • 性能测试
    以预期设定的性能值为目标，测试是否能满足预期
  • 负载测试
    不断加压到安全临界值
  • 压力测试
    超过安全负载直到崩溃下的最大负载

下图中的横坐标表示消耗的系统资源，纵坐标表示系统处理能力（吞吐量）。在开始阶段，随着并发请求数目的增加，系统使用较少的资源就达到较好的处理能力（a～b段），这一段是网站的日常运行区间，网站的绝大部分访问负载压力都集中在这一段区间，被称作性能测试，测试目标是评估系统性能是否符合需求及设计目标；随着压力的持续增加，系统处理能力增加变缓，直到达到一个最大值（c点），这是系统的最大负载点，这一段被称作负载测试。测试目标是评估当系统因为突发事件超出日常访问压力的情况下，保证系统正常运行情况下能够承受的最大访问负载压力；超过这个点后，再增加压力，系统的处理能力反而下降，而资源消耗却更多，直到资源消耗达到极限（d点），这个点可以看作是系统的崩溃点，超过这个点继续加大并发请求数目，系统不能再处理任何请求，这一段被称作压力测试，测试目标是评估可能导致系统崩溃的最大访问负载压力。

image

性能测试反应的是系统在实际生产环境中使用时，随着用户并发访问数量的增加，系统的处理能力。与性能曲线相对应的是用户访问的等待时间（系统响应时间），如图所示。

image

在日常运行区间，可以获得最好的用户响应时间，随着并发用户数的增加，响应延迟越来越大，直到系统崩溃，用户失去响应。

性能测试报告

测试结果报告应能够反映上述性能测试曲线的规律，阅读者可以得到系统性能是否满足设计目标和业务要求、系统最大负载能力、系统最大压力承受能力等重要信息，下表是一个简单示例。

image

 

 

可用性

高可用的应用服务器

构建高可用的应用服务器关键是session的处理，如果能使得每天机器上处理的请求都无状态，即可实现应用服务器的线性伸缩；服务器宕机后也可随时将请求放到其它机器上再次处理；
而对于需要处理状态信息的应用，解决方案是让每台机器使用共享的Session服务器，本地上还是无状态特征；

高可用的服务

设计要点

  • 分级管理
    区别核心应用和一般应用；在流量增加到超过网站的处理能力时，为了保证核心应用的可用性，可以将一般应用的服务停止，将资源让位给核心服务；
    比如博客中的博文显示和博客的评论功能；
  • 超时设置
  • 异步调用
  • 服务降级
    eg:twitter：随机拒绝部分请求
  • 幂等性设计
    保证多次调用结果一致

高可用的数据

CAP原理
一个提高服务的存储系统无法同时满足以下三个条件
一致性（Consistency）
数据可用性（Avalibility）
分区耐受性（Patition Tolerance，系统具有跨网络分区的伸缩性）

WEB架构设计中，通常为了保证高可用性，会牺牲一致性；

数据一致性分为：强一致、用户一致、最终一致；
大型WEB站点一般只保证数据的最终一致性；

扩展性

在网站新增业务产品时，实现对现有产品无影响，透明上线新产品。
主要手段

  • 事件驱动
    利用消息队列实现
  • 分布式服务
    将业务和可复用服务分离开

伸缩性

通过不断向集群中加入服务器的手段来缓解不断上升的用户并发访问压力。
可能加入的服务器有以下4类，其伸缩性能各不相同；

应用服务器

通过设计实现集群内服务器对等，使用合适的负载均衡可保证良好的伸缩性；

缓存服务器

缓存服务器伸缩性良好，但新加入服务器后可能导致缓存路由失效；
通过改进缓存路由算法，比如Memcached的一致性Hash，可实现加入新的缓存服务器后对原有缓存的影响尽量减少；

数据库服务器

很难做到大规模集群的可伸缩性
实现方式有：读写分离、数据表分库
（单表拆分：Cobar）
也可考虑伸缩性方案在数据库之外实现（通过路由分区）

NoSql产品

Nosql数据库就是为海量数据而生，可轻松实现集群规模的线性伸缩；
（Hbase使用Zookeeper选举master）

安全性

99.99%的设计标准：无单点、在线更新、自动切换

附：思维导图

卓越亚马逊地址： 《 大型网站技术架构》
点击查看原图

架构核心五要素

Posted by: 大CC | 13APR,2014
博客： blog.me115.com [ 订阅]
微博： 新浪微博

作者：liudong1105 发表于2014-4-16 20:34:24 原文链接
阅读：35 评论：0 查看评论

相关 [架构 核心] 推荐：

架构核心五要素

- - CSDN博客推荐文章
架构设计中要考虑的核心五要素；. 性能、可用性、扩展性、伸缩性、安全性. 应用执行一个操作需要的时间，包括从发出请求开始到收到最后响应数据所需要的时间. 响应时间是系统最重要的性能指标，直观地反映了系统的“快慢”. 下表列出了一些常用的系统操作需要的响应时间. 单位时间内系统处理的请求数量;. 如：TPS、QPS（每秒查询数）.

架构的核心要素

- - 掘金 架构
所谓架构，一种通俗的说法就是“最高层次的规划，难以改变的决定”，这些规划和决定奠定了事物未来发展的方向和最终的蓝图. 而软件架构即“有关软件整体结构与组件的抽象描述，用于指导大型软件系统各方面的设计”. 一般来说软件架构需要关注性能、可用性、伸缩性、扩展性和安全性这5个架构要素. 性能是网站架构设计的一个重要方面，任何软件架构设计方案都必须考虑可能带来的性能问题.

企业架构-分析的核心思路

- - 人月神话的BLOG
对于架构分析的入口点，仍然推荐是从端到端流程分析入手，细化到业务域的端到端，再细化到3,4级流程，最终细化到EPC最底层流程图. EPC流程图既是流程，本身也是业务功能. 还有一条线可能是直接从业务活动收集和组合入手，如根据业务部门，岗位角色划分，从组织架构和岗位职责直接收集业务功能点. 第一种方法既看到面又看到点，从上到下；而第二种方法则是容易只看到点，仍然无法贯彻整个企业端到端流程.

Android层次化安全架构及核心组件概览

- - 酷勤网-挖经验 [expanded by feedex.net]
Android系统承袭了Linux开源操作系统的安全特性，并采用了层次化的方式来保证系统安全，本文将详细介绍Android层次化安全架构及其核心组件. Android层次化安全架构. Android作为一个移动设备的平台，其软件层次结构包括了一个操作系统（OS），中间件（MiddleWare）和应用程序（Application）.

企业架构和IT规划咨询核心逻辑-2014(210217)

- - 人月神话的BLOG
注：今天整理自己写过的关于企业架构和IT规划咨询方面的文章，对于企业架构规划方法给人最大的一个思考就是将其和SOA，和云计算架构思想的融合，并理清四大架构之间的协同和集成关系. 企业架构（Enterprise Architecture EA）是从企业全局的角度审视与信息化相关的业务、信息、技术和应用间的相互作用关系以及这种关系对企业业务流程和功能的影响.

架构

- - IT瘾-dev
网关：Nginx、Kong、Zuul. 缓存：Redis、MemCached、OsCache、EhCache. 搜索：ElasticSearch、Solr. 熔断：Hystrix、resilience4j. 负载均衡：DNS、F5、LVS、Nginx、OpenResty、HAproxy. 注册中心：Eureka、Zookeeper、Redis、Etcd、Consul.

Android核心功能

- - 技术改变世界 创新驱动中国 - 《程序员》官网
Android功能模块的概况，就像看Android的“个人简历”一样，帮助我们对它的能力有整体上的认识，进而在应用开发之前可以更好地评估技术上的可能性和风险性. 每个Android开发者都会关心Android到底能够打造怎样的用户界面（User Interface，UI）. Android界面框架中最有特色的部分是资源（Resource）和布局（Layout）体系，通过完善的控件库和简明的接口设计，开发者可以尽快搭建自己需要的界面.

matplotlib核心剖析

- - 博客园_首页
作者：Vamei 出处：http://www.cnblogs.com/vamei 欢迎转载，也请保留这段声明. matplotlib是基于Python语言的开源项目，旨在为Python提供一个数据绘图包. 我将在这篇文章中介绍matplotlib API的核心对象，并介绍如何使用这些对象来实现绘图.

信息架构

- Michael - Tony-懒得设计
写几篇关于信息架构的文章，系统地输出我理解的信息架构. 发了一篇关于招信息架构实习生的博客，收到不少简历. 但谈起信息架构，多数不了解，稍微了解的扯了很多很偏的东西. 随手搜索了一下，我发现了原因：. 1 《web信息架构》这本书太概念，太学术. 2 有人绑架了“信息架构”这个词，拿出去唬人，内容都是皮毛或者是根本和信息架构不沾边的东西.