企业级系统架构设计技术与互联网应用技术结合主题一 大规模并发性能问题探讨

何谓大规模并发,不同层面有不同的理解

企业应用(Intranet):千级强并发,万级弱并发(在线用户),十万级用户

  • 大型企业ERP、供应链,大型企业HR、办公OA

互联网应用(Internet):百万级强并发,千万级弱并发(在线用户),亿级用户/

  • 门户网站(新浪、腾讯)
  • 平台级电子商务(阿里巴巴、淘宝网、拍拍网)
  • 搜索引擎(百度)

电子商务企业应用(Intranet + Internet):十万级强并发,百万级弱并发(在线用户),千万级用户

  • B2C电子商务(京东、凡客、一号店)
  • 垂直型电子商务(金银岛、携程)

不同系统间的并发特点
企业系统
大量事务性、实时性访问

  • 大量的事务、锁检测导致数据库访问瓶颈
  • 需要数据操作的实时更新

大量有状态性访问

  • 数据访问具有较强的操作上下文
  • 数据一致性、准确性的高敏感
  • 数据每一次事务性更新都必须得到充分展现,并且确保数据访问的一致性

清晰的业务逻辑进行并发划分

  • 一般来说,企业系统都可以进行明确的业务区分,从而决定系统特点

互联网系统
海量非事务性访问

  • 极其巨大的数据量及数据访问导致IO操作成为瓶颈

模糊的并发区分

  • 并发访问的用户中很难通过内容进行有效分发
  • 并发访问一般具有地域性

数据访问效率的高敏感

  • 用户对系统的响应时间非常敏感,需要在几秒内得到信息反馈
  • 用户更加在意数据的匹配性

电子商务系统
数据实时性的高敏感
价格、信息同步的一致性等
受制于企业级系统的约束

  • 如支付,受事务性影响

海量非事务性访问+一定规模事务性访问
信息访问具有互联网系统特点、信息操作具有企业系统特点

  • 如数据的搜索查询、展现具有互联网系统特点
  • 如数据的操作(支付、结算)具有企业系统事务性特点

什么是性能问题

  • 在可识别的压力下,系统无法提供服务 (最差的性能问题)
  • 在可识别的压力下,系统无法按服务质量标准提供服务 (满足性能标准,但是健壮性不足)
  • 在可识别的压力下,系统无法持续按服务质量标准提供服务 (系统的可靠性和健壮性)
  • 在超过识别的压力下,系统无法尽快恢复
  • 能否有故障转移、故障恢复、冗余热备等机制
  • 在超过识别的压力下,系统无法柔性伸缩 (系统的可伸缩性)

什么不是性能问题

  • 超过可识别的压力情况下,系统暂时无法有效提供服务

性能测量
服务质量

  • 网络响应:网络响应时间、网络吞吐量、网络带宽及带宽利用率
  • 服务响应时间:包括平均、峰值、标准区间值
  • 服务处理质量:事务成功率、单位时间响应事务次数

服务端设备状态

  • CPU:CPU使用率
  • 内存:使用内存大小
  • VM:GC次数(Full GC次数)、堆内存、线程数、锁和阻塞情况
  • 磁盘IO:磁盘访问效率、磁盘空间、磁盘IO吞吐量

系统可靠性、健壮性

  • 单节点处理的访问量
  • 故障恢复时间
  • 节点复制和节点扩展的难易

系统可能的性能瓶颈
网络

  • 网络带宽的总体限制
  • 网络连接数的限制(如TCP/IP, 数据库连接等)

服务器

  • 每个响应占用相应的资源,导致内存成为瓶颈
  • 比如JVM为每个线程分配栈空间,过多栈空间导致内存消耗
  • 比如每个HTTP连接在Session存储内容,导致OOME
  • 同时响应一定量的并发操作,导致CPU占用过高

磁盘IO

  • 频繁访问数据库,导致数据交换IO操作频繁
  • 频繁访问IO文件,导致磁盘IO成为瓶颈

企业级系统架构及技术特点
架构设计
基于SOA和MDA的架构

  • 以服务为核心单元的 设计思想,以传统WS作为服务发布
  • 以模块化为系统构建方式,重视应用子系统和子模块的独立性和可重用性

中央集中式部署架构

  • 专业小型服务器
  • 一般不会超过5台部署服务器,不会多于10个应用节点
  • 热备和故障恢复机制、灾备系统

关注流程

  • 工作流技术,尤其是分布式节点间流程整合
  • 企业系统间的无缝转移

门户

  • 跨系统,跨节点间的单点登录

技术运用
以商业性产品为主

  • 追求单节点稳定性
  • 较少需要7*24小时支持
  • 以商业性关系数据库为主要存储

比较严格的事务性访问

  • 完全基于数据库事务
  • 分布式事务(JTA)

较为复杂并且功能丰富的用户界面

  • 用户具有相对统一的客户端(比如使用IE浏览器)
  • 用户可以接受适当的响应和延迟

互联网系统架构及技术特点
架构设计
以界面展现和用户体验为主要设计

  • 大量运用Ajax实现局部提交和局部刷新

以轻量级、伸缩性为架构主要考虑

  • 除某些平台级应用外,极少使用服务扩展
  • 使用REST风格的WebService或者纯粹的处理Json的Web响应
  • 数以百台甚至上万台PC服务器,多个数据中心,站点镜像
  • 分布式独立域以及部署域之间定时通信

高性能缓存机制

  • 双向页面缓存
  • 内容静态化技术
  • 数据缓存

非事务、非关系型数据库

  • 全面NoSQL数据库

技术运用
大量使用开源技术产品

  • LAMP: Linux + Apache + MySQL + PHP
  • Tomcat, Lucene, Memcache

简单界面开发技术

  • 脚本语言,如PHP, Python, Ruby等
  • 对多种浏览器的支持

底层高性能处理优化

  • 使用C、C++实现底层通信和IO优化

电子商务系统架构及技术特点
架构设计
关注数据的糅合(Mashup)
关系数据库与高性能NoSQL数据库结合
不固定的架构设计思路

  • 可能偏互联网方向,也可能偏企业系统方向
  • 分布式部署

事务缓存机制

  • 事务迁移、事务恢复、事务批量处理

较为严格的安全机制

  • 部分功能使用HTTPS及数字证书

与企业系统的对接交互

  • 与银行、支付平台的对接
  • 与企业订单系统、进销存系统、物流系统的对接

技术运用
有时效的缓存机制

  • 确保数据实时性与性能的平衡

大量数据挖掘和分析运用

  • 相关性分析
  • 定向推荐

部分运用商业中间件技术产品

  • 应用服务器
  • 业务流程管理

大量的开源技术运用

  • Java相关开源技术比较常见

更多内容请关注微信公众号:it_haha

时间: 2024-08-17 14:43:00

企业级系统架构设计技术与互联网应用技术结合主题一 大规模并发性能问题探讨的相关文章

[转]专访企业QQ SaaS团队,谈企业级LNMP架构设计

FROM : http://www.csdn.net/article/2014-08-20/2821302-interview-tencent-b-qq-shuai-wang 对比IaaS和PaaS,SaaS得到的关注显然要少一些.究其根本,不仅因为SaaS关注的是功能方面的探索,更偏向于某个领域或层面的实际应用,还归结于相较前两者,软件的云化已基本趋于成熟,些许突破并不能带来产业上的变革.然而,较少的关注并不意味着缺乏明星产品:放眼国外,企业级SaaS服务已成为许多公司的一项重要收益来源,比如

IM系统架构设计之浅见

背景:除去大名鼎鼎的QQ这款即时聊天工具,还有许多细分行业的IM,比如淘宝阿里旺旺.网易泡泡.YY语音.......恰巧公司产品也要开发一款基于我们自己行业的类IM系统,很有幸我担当了这个产品的架构师,核心代码编写.实现者.下面我近年来从技术上我对IM系统(即时消息的传输,不包括语音,视频,文件的传输)的理解和设计分享出来,浅薄之见,望大家别见笑,欢迎给出批评意见. 一.网络传输协议的选择 目前我知晓的所有IM系统传输即时消息无外乎使用UDP.TCP.基于TCP的http这几种协议中的一种或几种

电商峰值系统架构设计--转载

1.1 系统架构设计目录 摘要:双11来临之际,<程序员>以“电商峰值系统架构设计”为主题,力邀京东.当当.小米.1号店.海尔商城.唯品会.蘑菇街.麦包包等电商企业,及商派.基调网络等服务公司,分享电商峰值系统架构设计的最佳技术实践. 自2009年11月11日,淘宝商城(现名天猫)拉开网购狂欢节的序幕,各大电商的促销浪潮此起彼伏.此时的电商大战不仅是价格之争,更是技术的较量.如何设计电商峰值系统来更好地满足用户蜂拥而至的访问,如何在海量数据处理中实时发现有效信息并转化为商机,成为众多电商企业密

机票实时搜索系统架构设计

机票实时搜索系统架构设计 ? 不同的业务场景,不同的特征 ? 结合特征去进?设计和优化 ? 通?!=最优 ? 量体裁? 分布式系统的CAP理论 首先把分布式系统中的三个特性进行了如下归纳:    ● 一致性(C):在分布式系统中的所有数据备份,在同一时刻是否同样的值.(等同于所有节点访问同一份最新的数据副本) ● 可用性(A):在集群中一部分节点故障后,集群整体是否还能响应客户端的读写请求.(对数据更新具备高可用性) ● 分区容错性(P):以实际效果而言,分区相当于对通信的时限要求.系统如果不能

秒杀系统架构设计

秒杀活动的用户量可能是网站平时正常访问量的数百甚至上千倍,网站如果为了秒杀时的最高并发量而设计部署,就需要比正常运营多的多的服务器,而这些服务器在绝大部分时候都是用不着的,浪费惊人.所以秒杀业务不能使用正常网站的业务流程,也不能与正常网站业务共用服务器,必须设计部署专门的秒杀系统. 秒杀系统所面对的技术挑战: 1.对现有业务造成冲击 2.高并发下的应用.数据库负载 3.突然增加的网络及服务器带宽 4.直接下单 秒杀规则是到点了才能下单,而下单页面也只是一个普通的url,如果得到这个url则不用等

petshop4.0 具体解释之中的一个(系统架构设计)

前言:PetShop是一个范例,微软用它来展示.Net企业系统开发的能力.业界有很多.Net与J2EE之争,很多数据是从微软的PetShop和Sun的PetStore而来.这样的争论不可避免带有浓厚的商业色彩,对于我们开发者而言,没有必要过多关注.然而PetShop随着版本号的不断更新,至如今基于.Net 2.0的PetShop4.0为止,整个设计逐渐变得成熟而优雅,却又非常多能够借鉴之处.PetShop是一个小型的项目,系统架构与代码都比較简单,却也凸现了很多颇有价值的设计与开发理念.本系列试

NET ERP系统架构设计

解析大型.NET ERP系统架构设计 Framework+ Application 设计模式 我对大型系统的理解,从数量上面来讲,源代码超过百万行以上,系统有超过300个以上的功能,从质量上来讲系统应该具备良好的可扩展性和可维护性,系统中的功能紧密关联.除去业务上的复杂性,如何设计这样的一个协作良好的系统,搭建开发人员基础平台,一直是我研究的方向. SouceCounter(版本3.3.91.79)对源代码的统计信息如下: 下面来详细解析一下这个系统的设计架构,纯.NET技术架构方案,C/S W

5G 融合计费系统架构设计与实现(一)

5G 融合计费系统架构设计与实现(一) 随着5G商用临近,5G的各个子系统也在加紧研发调试,本人有兴全程参与5G中的融合计费系统(CCS)的设计.开发.联调工作.接下来将用几篇文章介绍我们在CCS实现过程遇到的挑战与架构设计的考量.相信这些宝贵的经验可以适用于更广的软件系统,免于重复地陷入软件开发的焦油坑. 5G系统由3Gpp定制统一的架构和协议规范,这也是电信行业一直以来通行的作法.不同的是,5G以前的规范3Gpp总是喜欢独树一帜,比如最出名的DCC(Diameter Credit Contr

Unity3D手游开发日记(2) - 技能系统架构设计

我想把技能做的比较牛逼,所以项目一开始我就在思考,是否需要一个灵活自由的技能系统架构设计,传统的技能设计,做法都是填excel表,技能需要什么,都填表里,很死板,比如有的技能只需要1个特效,有的要10个,那么表格也得预留10个特效的字段.在代码里面也是写死一些东西,要增加和修改,就得改核心代码,如果我要把核心部分做成库封装起来,就很麻烦了. 能不能做成数据驱动的方式呢? 改技能文件就行了,即使要增加功能,也只需要扩展外部代码,而不用改核心代码, 我是这么来抽象一个技能的,技能由一堆触发器组成,比