系统架构——可移植性,对称多处理,可扩展性

可移植性

windows被设计成可在多种硬件平台上运行。windows NT最初的版本支持x86和MIPS架构。对于DEC(被康柏收购,后与惠普合并)公司的Alpha AXP平台,尽管它是一个64位处理器,windows NT运行在32位模式,windows也尝试过支持。windows 2000开发期间,曾有一个原生的64位版本但后来没有被发布。在支持第四代处理器架构上,Motorola PowerPC也曾被加入到windows NT 3.51中。因为市场需求的改变,MIPS和PowerPC架构在windows 2000的研发中被丢弃了。随后,因为windows 2000仅仅支持x86平台,康柏也不再支持其旗下的Alpha AXP架构了。然后windows XP和windows server 2003开始支持3种64位的处理器家族:Intel Itanium IA-64,AMD64,和适用于x86平台的intel64位扩展技术(兼容AMD64架构,二者有细微差别)。后面两族处理器称作64位扩展系统,本书称其x64。(windows 是如何在64位操作系统系统上可以运行32位应用程序的会在第三章中解释)

windows在不同硬件架构和平台之间实现可移植性主要靠如下两个方法:

  • windows是分层设计的,系统底层有关具体处理器和平台的模块是独立分开的,这样系统的上层就可以屏蔽这些硬件的差异。两个保障系统可移植性的关键组件是kernel(Ntoskrnl.exe中)和硬件抽象层(HAL,于Hal.dll)。这两个组件在本章后面都有详细叙述。基于具体的硬件的函数(比如线程会话切换和门调度)在kernel中实现。因不同硬件(例如主板)而不同的函数位于HAL中。唯一剩余的组件,也是特定于硬件体系结构的,即内存管理,代码数量相当多,不过放眼整个系统又仅仅是个小数目而已。
  • windows的绝大多数代码都是C写的,部分掺杂C++。汇编被用在系统需要直接操纵硬件的部分(比如中断门句柄)或者非常注意性能的部分(如会话切换)。汇编语言不仅存在于kernel和HAL,在系统核心的其他部分也有(如实现互斥锁的一个模块),另外还有windows子系统内核模式的部分,甚至一些用户模式的库中也有汇编,如Ntdll.dll中进程创建的代码。(本章后面会解释)

对称多处理

多任务是操作系统把一个处理器在多个线程之间共享的技术。当一个电脑拥有多于一个处理器的时候,它就可以同时进行多个线程了。也就是说,单一处理器的系统仅仅是看起来像能同时处理多个线程,多个处理器的系统就是名副其实了,每个处理器处理一个线程。

本章开头说过,windows的设计目标之一就是能够在多处理器平台上运行。windows是一个对称多处理(SMP)系统,没有主处理器——系统和用户线程一样可以运行在任意一个处理器上。同时,所有的处理器共享同一个内存空间。如果系统选择其中一个处理器运行系统内核代码,另外的处理器运行用户代码,那样的模式叫非对称多处理(ASMP)系统。二者对比于图2-2。

windows也支持3种现代多处理器系统类型:多核,超线程,和NUMA(非统一内存架构)。这些在后面的段落中简要提及。(完全了解这些系统调度的细节,请参阅第五章“进程和线程”)

图2-2

超线程是intel提出的一项技术,它在cpu的每个物理核上模拟出两个逻辑处理器。每个逻辑处理器有他自己的cpu状态,但共享执行引擎和内建cache。这允许其中一个逻辑cpu停滞的时候(如cache未命中或者指令分支预测错误)另一个逻辑cpu运算。这种调度策略旨在最佳发挥超线程设备——调度选择一个忙的逻辑cpu同一物理cpu上的另一个闲置逻辑cpu好过选择一个闲置的物理cpu。更多线程调度的细节参看第五章。

在NUMA系统上,处理器被分为称作节点的组。每组都有其自身的处理器和内存,它们通过高速缓存互联总线连接到整个系统中。运行在NUMA系统上的windows依然是个SMP系统,所有的处理器要访问全部内存,这是背景。实际上访问节点自身的内存要快过访问其他节点的内存。对于处于同一节点可以访问同一内存的处理器之间调度线程,以此来改善性能。并且尽量在节点内部满足内存请求,但如果必要还是会从外节点分配内存的。

当然,windows也原生支持多核系统——因为这样的系统有真正的物理核,windows上原本SMP代码将他们看做离散的多处理器,除了某些需要区分同一cpu上不同核和远程核的计算和识别任务。

windows在原本的设计中并没有限制具体的处理器数量,同时用发放许可证的办法来区分不同版本的windows。为了方便和效率,windows会在一个掩码中追踪记录处理器(总数量,闲置数,使用数,等等细节),这个可以被cpu直接操作的掩码又称作关联掩码,其位数和机器位数(32位或64位一致)。因此windows系统这样又限制了cpu的数量,因为这个关联掩码不可任意增长。为了保持兼容性,满足支持大处理器的需求,windows实现了一个高级结构叫处理器群。整个处理器群可以被一个关联掩码定义,内核和应用程序均可指定由哪个组群执行。兼容程序可查询支持的组群数量(最近被限制在4个),遍历每个组群的关联掩码。同时,传统的应用程序依旧可以在一个族内运行无碍。更多信息关于windows如何分配处理器族(也有关NUMA)的细节参阅第五章。

上面提到,可支持的处理器数量取决于windows版本(见本章后面图2-2)。这个数字被保存在系统许可文件(\Windows\ServiceProfiles\NetworkService\AppData\Roaming\Microsoft\SoftwareProtectionPlatform\tokens.dat)中,作为一个公共变量“Kernel-RegisteredProcessors”。(注意,篡改这个数据违反软件许可证,要使用更多数量的cpu要改的不仅仅是这一个数据。)

可扩展性

多处理器系统的一个关键问题就是可扩展性。SMP系统为了保持运行的正确必须遵守严格的规定。资源争夺和其他的性能问题比单一处理器的系统更复杂,而且在系统设计中必须更重视。windows为此采取了多个策略:

  • 同时可让系统代码运行在一个或几个处理器上的能力
  • 一个处理器可运行多个线程,而每个线程又可被多个处理器执行
  • 内核,驱动和服务进程的高精度同步(如自旋锁,队列自旋锁,见第三章),让更多组件同时在多个处理器上协同运行。
  • 诸如I/O端口(第二部分第八章“I/O系统”)这样的编程机制使得多线程服务进程可以很好地运行在多处理器系统上。

windows系统的这些兼容性已经经过了长时间的演变优化。比如windows server 2003在多处理器上调度多线程提出的per-CPU调度队列,还有windows 7和windows server 2008 R2 在调度数据库中摒弃了全局锁。这种逐步的提高也发生在其他方面,比如内存管理。更多细节有关多处理器同步详见第三章。

时间: 2024-10-12 16:47:09

系统架构——可移植性,对称多处理,可扩展性的相关文章

高级系统架构师培训笔记

前几天参加了中科院计算所培训中心谢老师的高级系统架构师培训课程,将其中的一些点做了下记录: 系统架构师的工作是复杂设计总体解决方案以及领域对象的逻辑和物理布局,这是一项在复杂环境中高风险.高影响力的活动. 1.软件架构的定义:软件架构(Software Architecture)也称之为软件体系结构,它是一组有关如下要素的重要决策:软件系统的组织,构成系统的结构化元素,接口和它们相互协作的行为的选择,结构化元素和行为元素组合成粒度更大的子系统方式的选择,以及指导这一组织(元素及其接口.协作和组合

大型分布式电商系统架构是如何从0开始演进的?【转】

本文是学习大型分布式网站架构的技术总结.对架构一个高性能.高可用.可伸缩及可扩展的分布式网站进行了概要性描述,并给出一个架构参考.文中一部分为读书笔记,一部分是个人经验总结,对大型分布式网站架构有较好的参考价值. 一.大型分布式网站架构技术 1.大型网站的特点 用户多,分布广泛 大流量,高并发 海量数据,服务高可用 安全环境恶劣,易受网络攻击 功能多,变更快,频繁发布 从小到大,渐进发展 以用户为中心 免费服务,付费体验 2.大型网站架构目标 高性能:提供快速的访问体验. 高可用:网站服务一直可

大型分布式电商系统架构有哪些

1.大型网站的特点 用户多,分布广泛 大流量,高并发 海量数据,服务高可用 安全环境恶劣,易受网络攻击 功能多,变更快,频繁发布 从小到大,渐进发展 以用户为中心 免费服务,付费体验 2.大型网站架构目标 高性能:提供快速的访问体验. 高可用:网站服务一直可以正常访问. 可伸缩:通过硬件增加/减少,提高/降低处理能力. 安全性:提供网站安全访问和数据加密.安全存储等策略. 扩展性:方便地通过新增/移除方式,增加/减少新的功能/模块. 敏捷性:随需应变,快速响应: 3.大型网站架构模式 分层:一般

SOA系统架构

一.SOA原理与应用 1.SOA原理 SOA(Service-oriented architecture,面向服务架构). SOA的价值在于跨越了不同应用系统.不同技术的整合,这种整合改变现有的商业模型. SOA是在计算环境下设计.开发.应用.管理分散的逻辑(服务)单元的一种规范.这个定义决定了SOA的广泛性.SOA要求开发者从服务集成的角度来设计应用软件,即使这么做的利益不会马上显现.SOA要求开发者超越应用软件来思考,并考虑复用现有的服务,或者检查如何让服务被重复利用.SOA鼓励使用可替代的

IM系统架构设计之浅见

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

【iOS开发之旅】iOS系统架构

iOS的系统架构分为四个层次:核心操作系统层(Core OS ).核心服务层(Core Services ).媒体层(Media )和可触摸层(Cocoa Touch ).下面是IOS系统结构图. 一.Core OS(核心操作系统层) 是用FreeBSD和Mach所改写的Darwin, 是开源.符合POSIX标准的一个Unix核心.这一层包含或者说是提供了整个iPhone OS的一些基础功能,比如:硬件驱动, 内存管理,程序管理,线程管理(POSIX),文件系统,网络(BSD Socket),以

Android系统架构的简单描述

架构图如下: 1)英文版: 2)中文版: 由图可知:Android 系统架构从下到上分为 Linux内核层.中间件. 应用程序框架层和应用程序层. 1.Linux kernel 负责硬件的驱动程序.网络.电源.系统安全以及内存管理等功能. 2.中间件:核心库和运行时(libraries & Android runtime) 1)核心库 即c/c++函数库部分,大多数都是开放源代码的函数库,例如webkit(引擎),该函数库负责 android网页浏览器的运行,例如 标准的 c 函数库libc.o

日志收集分析系统架构

日志收集分析系统架构   一.部署架构 日志收集系统一般包括如图所示三层.Web服务器层,日志收集层,日志存储层.Web服务器层是日志的来源,一般部署web应用供用户访问,产生日志,该节点上一般需要部署日志收集程序的agent.日志收集层手机web服务器产生的日志传输给日志存储层,存储层一般使用分布式文件系统HDFS,日志可以存储在hdfs上或者hbase上. 以scribe作为日志收集系统架构,scribe分为scribe agent和scribe server 以kafka作为日志收集系统架

大型web系统架构详解

动态应用,是相对于网站静态内容而言,是指以c/c++.php.Java.perl..net等服务器端语言开发的网络应用软件,比如论坛.网络相册.交友.BLOG等常见应用.动态应用系统通常与数据库系统.缓存系统.分布式存储系统等密不可分. 大型动态应用系统平台主要是针对于大流量.高并发网站建立的底层系统架构.大型网站的运行需要一个可靠.安全.可扩展.易维护的应用系统平台做为支撑,以保证网站应用的平稳运行. 大型动态应用系统又可分为几个子系统: (1) Web前端系统 (2) 负载均衡系统 (3)