附录I-1 体系结构设计报告_百度文库
您的浏览器Javascript被禁用，需开启后体验完整功能，
享专业文档下载特权
&赠共享文档下载特权
&10W篇文档免费专享
&每天抽奖多种福利
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
附录I-1 体系结构设计报告
阅读已结束，下载本文需要
想免费下载本文？
定制HR最喜欢的简历
下载文档到电脑，同时保存到云知识，更方便管理
加入VIP
还剩7页未读，
定制HR最喜欢的简历
你可能喜欢&·&&·&发帖说明 本小组需要加入才可以发帖
[分享]结构设计嵌固端如何确定?
发表于&&&&1295人浏览&&&&1人跟帖&&&&筑龙币+50&&&&
高层建筑结构嵌固端位置的确定对计算结果的真实性和准确性有很大的影响，正确选取结构嵌固端，不仅对结构的位移角、基底剪力等结构整体指标有影响，还可以影响到结构的位移比、刚度比等楼层局部指标和内力分布、钢筋等。本文将为您介绍规范对嵌固端的计算和相关构造要求，阐述地下室顶板嵌固条件及不嵌固下移规范的处理方式，并结合PKPM结构设计软件相关的处理方式，加深您对于结构嵌固问题的理解和对实际工程问题的应对能力。前 &言建筑结构在进行结构分析计算之前必须首先确定结构嵌固端的所在位置，而嵌固端的选取按照《高层建筑混凝土结构技术规程》JGJ3-2010（以下简称“高规”）和《建筑抗震设计规范》GB（以下简称“抗规”）都要满足一定的条件，比如在地下室顶板嵌固需要满足相关范围内地下一层构件剪切刚度与上层构件剪切刚度比大于2，同时地下室顶板还需满足一定的构造要求，如果地下室顶板达不到嵌固条件，嵌固端下移，下移之后的嵌固端位置一般为地下室底板。实际工程中也由于各种特殊的情况，比如错层、夹层、坡地建筑、大底盘多塔结构等导致嵌固部位不太好确定，当然的确定也与是否有地下室、地下室层数的多少及基础形式都均有关系。不同的嵌固端位置会影响结构梁柱构件内力的调整、的高度、梁柱构件配筋放大的处理等，对于经济性会产生一定的影响。本文结合规范嵌固端相关要求，对当前设计中存在的一些问题进一步分析，加深设计师对于结构嵌固相关问题的理解及对提高设计师对实际工程问题的处理能力。对规范嵌固端的理解嵌固端包含两个层次的含义：1）计算嵌固端（计算模型的嵌固端或力学嵌固端，可理解为刚度嵌固端，简单理解被固定的位置）；2）设计嵌固端（预期塑性铰出现的部位或者强度嵌固端）。实际结构设计中，若不存在地下室，结构的嵌固端就是结构最底部，该部位是属于计算嵌固端，构件最底部不发生任何的平动和转动变形；若存在地下室，结构的计算嵌固端应该属于地下室的底板，但从规范精神出发，由于地下室土体约束作用的不确定性及线性地震加速度反应谱曲线属于地面反应谱等原因，为了在计算中得到明确的计算模型，规范认为地下室顶板构造满足一定的条件、地下一层相关范围构件剪切刚度与地上一层剪切刚度比大于2时，上部结构剪力可以可靠传递给地下室，地下室由于刚度大，且有土体约束，将产生较小的变形，仍应将地下室顶板作为上部结构设计的嵌固端，此时的嵌固端可以理解为设计嵌固端，该位置也是在结构设计中预期出现塑性铰的部位。不带地下室的结构，地震作用下结构塑性铰一般出现在结构最底部；对于带地下室的结构，由于地下室土体的约束作用，导致地下室顶板下层产生刚度突变，地震作用下可能使高层建筑的塑性铰由基础顶部转移到地下室顶板部以上。震害表明，在地震作用下，一般塑性铰出现在结构正负0处，但塑性铰也有向地下一层延伸的情况，基本未发现地下室底板出现塑性铰的情况。规范中为满足地下室顶板嵌固，保证塑性铰更加可靠的出现在地下室顶板以上部位，且保证塑性铰不要下移，对地下室结构的刚度和承载力提出了适当的加强措施，通过这样的调整，迫使塑性铰在预期的部位出现。规范中的嵌固端，涉及到结构设计中的强度、刚度及延性，其重点是得到较为准确的计算模型及保证抗震作用下的延性。通过确定嵌固端，得到清晰准确的计算模型，进行内力分析、配筋设计及规范指标判定。嵌固端位置的确定1.不带地下室结构嵌固端位置的确定按照上述分析，对不带地下室的结构，结构嵌固端位置是结构最底部，在进行内力分析与配筋设计时，结构最底部既是力学意义的嵌固端也是设计意义的嵌固端，底部节点既不发生平动也不发生转动变形。2.带地下室结构嵌固端位置的确定对于带地下室的结构，按照规范要求，应将上部结构与地下室“相关部位”（地上结构外扩不超过三跨的地下室范围）构件一起进行整体分析，按照高规附录E.0.1进行剪切刚度比的计算，如果地下一层“相关部位”构件剪切刚度与上层剪切刚度比大于2，地下室顶板可以作为上部结构的嵌固端。如果地下一层“相关部位”构件剪切刚度与上层剪切刚度比不大于2时，地下室顶板无法作为上部结构嵌固部位，嵌固端下移，移动的嵌固端位置应该为地下室底板，此时规范设计嵌固端也就是计算嵌固端，不应将中间某层设置为嵌固端所在的楼层。是否能在地下室中间某楼层嵌固，规范并没有给出相关的计算条件，不能直接按照下层比上层剪切刚度比大于2去判定嵌固，还需要考虑下层为地下室这一容易被设计师所忽略的隐含重要信息，正如上部结构计算中不能认为某一层与上层刚度比大于2，就将该层位置作为嵌固一个道理。规范没有表明在地下室中间楼层位置嵌固的条件，不能盲目扩大剪切刚度2倍的使用范围。因此，如果地下室顶板不能作为上部结构的嵌固端时，应将嵌固端移至结构的最底部，即地下室底板。顶板嵌固相关问题1.上部结构的配筋及指标控制由于土体约束的不确定性，应尽量通过调整结构布置，满足地下室顶板嵌固的剪切刚度比要求，保证地下室顶板作为上部结构的嵌固端。当地下室顶板为上部结构的嵌固部位时，应按取消掉地下室进行上部结构的内力分析、配筋设计及规范相关控制指标的判定。地下室部分不进行地震作用的分析，上部结构计算的剪力即基底剪力通过地下室的顶板直接传递给地下室，在地下土体约束作用下，上部地震作用仅仅传给地下一层，不再向下传递。诸如，刚度比、刚重比、剪重比、周期比、位移比及层间位移角指标，也应该是在取消掉地下室的模型上计算得到的，并与规范限值进行比较。2.地下室地震作用分析按照高规3.9.5条的相关要求，地下室顶板作为上部结构嵌固部位时，规范要求地震作用下结构的屈服部位发生在地上楼层，同时将影响地下一层，地面以下结构的地震响应由于土体作用逐渐减小，规定地下一层抗震等级不降低，地下一层以下不要求计算地震作用，其抗震构造措施抗震等级逐层降低。规范认为当地下室顶板嵌固以后，按正负0以上结构计算的地震剪力，通过满足加强措施的地下室顶板传递给全部地下室，并主要由地下一层构件承担。3.地下室土体约束的考虑&&&&用于判断地下室顶板是否嵌固的剪切刚度与土体约束无关，但土体约束影响结构整体计算的刚度及内力，进而影响配筋。地下室层土体约束大小规范并没有给出具体值，当前设计一般都按照弹簧方式模拟土体作用，在SATWE软件中可以通过填写定义地下室，并填写“X、Y方向土层水平抗力系数的比例系数m值”来反映土体的这种约束作用。m值按照《建筑桩基技术规范》JGJ94-2008（以下简称“桩基规范”）中表5.7.5的灌注桩对应的地基土类型去确定，m值越大，对应的土体对结构整体的约束作用越强。如果m值填写为负值，比如三层地下室填写m=-3，代表地下两层在X、Y两个水平方向实现完全的嵌固，地下室不产生水平位移，但土体不会约束转动方向位移，地下室会产生转动方向的转角变形。4.地下室构件配筋的加强措施对地下室顶板嵌固的结构，为保证塑性铰不要出现在地下室，而出现在地上楼层，规范要求地下室结构的刚度和承载力做适当加强。地下室顶板满足梁板体系、最小板厚180、混凝土标号大于C30、最小配筋率0.25%等构造要求；地下一层梁、柱、墙等构件抗弯承载力做了提高，要求嵌固端下一层柱构件配筋单侧配筋是上层柱单侧配筋的1.1倍，梁构件支座部位按组合弯矩乘以1.3进行配筋，墙体边缘构件要求本来可设置构造边缘构件的，但要求纵筋面积不小于上层约束边缘构件纵筋面积。同时地下室构件配筋还要满足计算要求。顶板不嵌固相关问题1.地下室顶板不嵌固的内力分析与配筋设计抗规6.1.10.3强调了当结构计算嵌固端位于地下一层的底板或以下时，宜向下延伸到计算嵌固端。当地下室顶板无法作为上部结构的嵌固端时，规范要求嵌固端下移，此时一般设计师会直接将地下室和上部结构一起建模计算，按照桩基规范填写X、Y方向土层水平抗力系数的比例系数m值，完成上部与地下室的配筋。在配筋设计阶段嵌固端所在的层号对配筋处理有较大影响。如果是一层地下室，嵌固端填写1与2计算内力及配筋结果完全一样，导致很多设计师不用为了满足顶板嵌固而加大地下室墙柱构件的截面，直接将嵌固端放在地下室底板。对一层地下室结构，嵌固端位置不同，虽然计算结果完全一致，但不符合规范精神，应尽量通过加大地下室相关范围构件截面尺寸，做到在地下室顶板嵌固。带多层地下室结构，假如有4层，顶板若不嵌固，设计师会将嵌固端下移到地下一层底板作为嵌固端，此时，地下一层底板能否作为嵌固端，需要根据剪切刚度比去判断，部分设计师以地下二层剪切刚度与地下一层剪切刚度比是否大于2来判断是否嵌固，也有部分设计师以地下二层与地上一层剪切刚度比是否大于2判断是否嵌固。这样就有“嵌固端所在层号”为地下室中间某层，2或3或4等多种情况，按照规范若顶板不嵌固，应该只有嵌固端所在层号为1这种情况。在SATWE计算中如果将地下室与上部结构一起计算，填写嵌固端所在层号为3，内力分析与嵌固端所在层号填写无关，配筋设计时，考虑底部加强区下延，约束边缘构件延伸到嵌固端层，相应楼板、梁及柱对应的构造及配筋均做加强处理，柱单侧配筋1.1放大一直延伸到嵌固端，梁支座弯矩1.3放大不仅放大地下一层位置的，也放大嵌固端所在层号下一层的。当然对于地上结构配筋很多设计师由于把握不准确土约束大小，而采取了按照带地下室模型整体计算与不带地下室模型计算，对上部配筋包络设计。2.地下室顶板不嵌固的结构指标控制由于土体约束的不确定性，虽然可以按照桩基规范表5.7.5去填写，但这是一个范围，在进行结构内力分析时，设计师对相同的土体约束情况可能赋予不同的m值，这样会导致计算模型由于不同的刚度而引起各项指标可能有差别。设计中关注的结构整体指标位移角、基底剪力、刚重比与结构楼层指标层刚度比、位移比、剪重比等这些指标就很难把握。部分设计师可能认为考虑地下室土体约束情况，计算的各项指标更准确，但由于土体约束的不准确，此结果与规范限值控制需要的计算模型结果是不对等的。因此，即使地下室顶板不嵌固，在进行这类结构指标控制的时候，建议还是按照取消掉地下室的模型进行控制。与嵌固端相关细部问题1.底部加强区的确定及软件处理抗规6.1.10、高规7.1.4及对应条文说明对结构底部加强区的确定综合可概括如下。如果是地下室顶板嵌固，底部加强区为：max（H/10，顶板算起底部两层，有裙房层数时裙房层数加1，有转换层层数时转换层层数加2）；如果是地下室顶板不嵌固，嵌固端下移，底部加强区下延，此时的H始终从地下室顶板算起。软件在处理规范这条时不完全与规范一致，对于H的取值，如果顶板嵌固，从正负0算起，如果嵌固端下移，H高度跟着下延。同时由于规范要求嵌固端下一层构造边缘构件纵筋大于上层约束边缘构件纵筋，软件对于底部加强区按照上述方式确定以后还下延一层。当然对于底部加强区高度也允许设计师进行任意楼层指定干预，如图1所示。图1 底部加强区人工干预图2.地下室顶板嵌固刚度比的判断及软件处理地下室顶板是否嵌固时，需判断地下一层“相关范围”内楼层剪切刚度与上层的剪切刚度比，按照抗规6.1.14.2、高规5.3.7及高规附录E.0.1可知，该剪切刚度比仅与层高、竖向构件截面尺寸有关，与土体约束无关。在使用SATWE软件进行该项判断时，需要带地下室模型做整体分析，m值默认即可，因为此值不影响剪切刚度比的计算。程序在计算剪切刚度比的时候采用的是本层刚度与下一层的刚度比，因此，如果查看地下室顶板能否嵌固，带着地下室计算，查看正负0 层剪切刚度比RATX与RATY两值是否小于0.5来判定。3.嵌固端抗震等级确定及软件处理按照抗规6.1.3及高规3.9.5，地下室顶板嵌固以后，地下一层相关范围内抗震等级同上部结构。地下一层及以下抗震构造措施抗震等级逐层降低，但不应低于四级，地下室超出上部主楼相关范围且无上部结构的部分，其抗震等级可根据具体情况采用三级或四级；顶板嵌固以后，地震剪力从上部仅传给地下一层，不再向下传递，实际上是抗震构造措施抗震等级为三级或四级。在SATWE软件中默认地下室构件抗震等级同上部结构的抗震等级，对嵌固端以下抗震构造措施抗震等级可逐层降低，如图2所示。在实际设计中对于地下一层及以下需要手工修改抗震等级及抗震构造措施的抗震等级，如图3所示。图2 抗震构造措施抗震等级逐层降低选项图图3 抗震等级及抗震构造措施抗震等级修改图4.嵌固端相关结构底部薄弱层判断及软件处理高规3.5.2对底部嵌固层是否是薄弱层提出了较高的要求，由于底部嵌固层层间位移角结果较小，规范对其与上一层侧向刚度比做了150%的要求。此处侧向刚度比指的是层剪力与层间位移的比值，如果有土体作用，该比值与土体约束有关。设计中需正确的处理结构模型，正确进行首层刚度比的计算，并进行首层是否是薄弱层的判定。SATWE软件中为了正确的去判断首层是否是薄弱层，需要取消掉地下室去计算首层与上层的刚度比。程序对于高规3.5.2的执行仅仅针对结构建模计算的首层执行刚度比150%的较高要求。需要注意的是，如果带地下室计算，程序仅对结构地下室最底部按照150%控制刚度比，对正负0这一层并不会执行规范的这条要求。直接查看3.1.6版本软件输出的首层的RATX2与RATY2，查看这两个值是否大于1.5进行薄弱层的判断（注意：2.2及以前版本这个刚度比已经考虑1.5的值，直接与1比较即可）。5.嵌固端相关底层剪力及倾覆力矩计算及软件处理高规4.3.12与抗规5.2.5对结构的底部最小剪力均提出了要求，要进行规范这项最小剪重比的判断，需要准确计算结构底部剪力。抗规和高规中要求通过计算的框架柱所占的倾覆力矩的比例确定相应的框剪结构的设计方法，倾覆力矩的计算是指嵌固端所在层即正负0处的计算结果。SATWE软件为了准确的考虑上部结构的剪力及倾覆力矩，在上部结构和地下室一起共同计算时，考虑地下室回填土的刚度贡献，但是有效质量系数的计算程序是不考虑地下室的，仅仅按照上部结构去统计有效质量系数。按照满足上部有效质量系数90%下计算的地下室顶板处的基底剪力进行最小剪重比调整及倾覆力矩的计算，底层倾覆力矩是嵌固端所在层的倾覆力矩。6.嵌固端相关转换柱的弯矩放大高规10.2.11中要求对于一、二级转换柱的顶上端和下端弯矩组合值分部乘以放大系数1.5,1.3。设计师需要注意，按照规范体系，转换柱这条的放大需要正确理解嵌固端情况下执行，正确定义转换柱。在SATWE程序中需要正确定义转换柱，程序才可以按照规范要求正确放大其顶部和底部，需要设计师注意的是，如果带地下室计算，转换柱底部定义到正负0 层即可，不要延伸到地下室，否则规范要求的放大没有正确执行。如果不带地下室，就应该定义转换柱从正负0到转换柱顶。7.嵌固端相关剪力墙轴压比、边缘构件判断及软件处理设计师在设计中发现不带地下室计算的剪力墙轴压比基本符合从底到顶轴压比逐渐减小，但是带地下室以后，导致剪力墙轴压比分布与概念判断不太相符，这主要是由于地下室土体约束引起的，土体约束导致地下首层刚度突变，剪力墙分担的恒活荷载也变化，进而引起轴压比在正负0处也会发生突变。对于剪力墙轴压比计算是采用重力荷载代表值作用下的轴力，恒活作用下的轴力与结构刚度有关，与土体约束有关。SATWE软件中，程序仅判断嵌固端所在楼层的剪力墙轴压比是否满足可设置构造边缘构件的条件。如果带地下室计算，即使嵌固端以上楼层轴压比大于表7.2.14的限值，嵌固层轴压比小于表7.2.14要求，程序仍然会一律设置构造边缘构件。在软件中参数设置如图4所示。图4 按抗规6.4.5是否设置构造边缘构件8.嵌固端相关强柱根调整及软件处理为了提高结构安全度，高规6.2.2要求对于底层柱弯矩进行放大（强柱根调整），以加强底层柱下端的实际受弯承载力，推迟塑性铰的出现。此处底层柱弯矩方法系数应该仅仅对结构正负0的底层柱进行放大即可。SATWE软件对地上一层、嵌固端和地下室底层的柱底弯矩都做了调整。如果建模计算中地下室参与结构整体分析，不论地下室顶板是否达到嵌固要求与否，地上一层天然存在一个或强或弱的被嵌固效果。地震灾害分析报告中绝大多数工程的地上一层都属于结构的最薄弱部位，极少见到地下室结构发生严重破坏的。为确保工程安全，软件按此进行控制虽然是保守的，但是必要的。9.嵌固端相关部位梁、柱、墙配筋放大及软件处理按照抗规6.1.14及高规12.2.1可知，对于地下室顶板作为上部结构嵌固端时，嵌固端下层的梁端实配抗震受弯承载力大于地上柱下端实配抗震受弯承载力的1.3倍；柱嵌固端下层柱单侧配筋不小于地上一层柱的1.1倍；墙嵌固端下层边缘构件纵筋面积不小于地下一层对应墙肢边缘构件的纵筋面积。SATWE软件对地下一层即嵌固端下一层柱构件配筋单侧配筋取上层柱单侧配筋的1.1倍与自身计算的大值，柱上下截面形式不一致时，程序不会自动做这个1.1放大。地下一层梁支座部位程序按组合后的弯矩乘以1.3进行配筋，未完全按照规范要求进行处理，同时这个放大也是有条件的，需要梁的两端均有竖向构件相连，并且梁端上部也需要有柱，同时还要满足地震作用组合，同时满足这三个条件，才执行端部1.3放大。地下一层墙体边缘构件要求本来可设置构造边缘构件的，但程序判断该层为底部加强区，认为属于约束边缘构件，在满足自身计算配筋的同时，取纵筋面积不小于上层约束边缘构件纵筋面积，两者取大。如果嵌固端不在地下室顶板，则嵌固端下移，如果嵌固端移到结构最底部，比如有四层地下室，则地下四层柱配筋均取地上一层柱单侧配筋1.1倍与计算的大值。对于梁端配筋，不仅地下室顶板梁支座部位按组合后的弯矩乘以1.3进行配筋，嵌固端所在层梁端支座也按照组合弯矩乘以1.3进行配筋。由于嵌固端下延，地下室均设置约束边缘构件，且配筋均取首层约束边缘构件配筋与自身计算配筋的大值。放大处理的理由是，与柱底设计内力的放大原则相同，一句话概括为：“地下室顶板处总是按照嵌固端设计”。结束语高层建筑结构设计中，由于土体的不确定性，结合规范要求，分析了关于内力、配筋及指标等各方面的问题，建议结构的嵌固端尽量设置在地下室顶板，如果无法在顶板满足下层与上层剪切刚度比不大于2，嵌固端下移至地下室底板。对于土体的约束如果输入m值，程序可以按照输入的值，体现土对结构的约束作用。实际设计中，无论选择地下室顶板还是结构最部位作为结构嵌固端，程序都通过相应的措施对梁、柱、墙及板配筋做了有针对性的加强，确保塑性铰尽可能出现在结构正负0，避免塑性铰向下延伸。本文同时结合设计师常用的SATWE设计软件对于嵌固端相关问题的处理及理解进行了详细的分析，供设计师在设计中参考。参 考 文 献[1] GB建筑抗震设计规范[S].北京：中国建筑工业出版社，2010.[2] JGJ3-2010高层建筑混凝土结构技术规程[S].北京：中国建筑工业出版社，2010.[3] JGJ94-2008建筑桩基技术规范[S].北京：中国建筑工业出版社，2008.
分享到微信朋友圈
打开微信"扫一扫"，扫描上方二维码请点击右上角按钮&，选择&
&&发表于&&|&
&& &&筑龙币+10
正确选取结构嵌固端，不仅对结构的位移角、基底剪力等结构整体指标有影响，还可以影响到结构的位移比、刚度比等楼层局部指标和内力分布、钢筋等。
后才能评论,评论超过10个字，有机会获得筑龙币奖励！
筑龙学社APP扫码
立即免费下载资料
只需1元，认证E会员，百万资料免费下
【微信扫码支付】
您已成功认证为E会员
还可以输入&120&字
他一定是哪里做的不够好，别替他瞒着了，告诉我们吧~
:&400-900-8066只有那些有目标，有爱， 有激情，能坚持到底的灵魂，才能走出一路不断的生机盎然，活出一个越来越大的世界...
架构风格与基于网络的软件架构设计
架构风格与基于网络的软件架构设计
如今许多服务都采用了 RESTful API, 而 REST 这一架构风格，最早即来源于 Roy Thomas Fielding 的博士论文
，本文即是阅读此文后的总结，并结合论文给出大量实例。通常人们都是因为 RESTful 风格才提到这篇论文，有的人甚至只读涉及 REST 的那章。但是我读完论文后，感觉最大的收获不是 REST 这一架构风格，而是为基于网络的软件设计架构时，应该考虑哪些因素，不同的因素会导致哪些不同的结果。因此，本文将重点对基于网络的软件架构进行介绍，而非介绍 REST 本身。
首先介绍一下作者，Roy Thomas Fielding。
Fielding 博士是 HTTP/1.1 规范的主要制定者，并且深度参与了 URI, HTML 规范的设计。同时是 Apache HTTP Server 项目的联合创始人，Apache 软件基金会的联合创始人，并在成立前三年担任软件基金会主席。Fielding 博士的这篇博士论文，是 Web 发展史上极其重要的文献，奠定了现代 Web 架构。可以看出，此人不仅理论功底扎实，还亲自写代码践行自己的理论。
Fielding 博士之所以写这篇论文，也与 Web 早期的发展状况有关。早期的
Web 架构，基于一些基本的原则，例如简单性，分离关注点，通用性，但是缺少对架构的精确描述。Web 早期只在政府及研究机构部署，但随着公众及商业公司的介入，Web 的规模在指数级增长，但早期的 Web 架构已经难以支撑这样的规模。因此，当时需要现代 Web 架构，来支持 Web 规模的极速增长，同时，也要避免新架构的引入，破坏了早期 Web 架构中一些良好的特性。因此，作者在论文中提出了 REST 架构风格，来指导现代 Web 架构的设计。这就是这篇论文出现的主要背景。
软件架构元素
我们经常听别人谈起 “软件架构”，“系统架构”，“架构师”，这样的名词。那么，到底什么是软件架构呢？Fielding 认为，软件架构主要由三部分元素组成：数据元素，连接元素，处理元素。
数据元素是指系统中被使用，被转化的信息，例如 HTML 文档，JPEG 图片等。
连接元素是将系统中不同部分连接起来的元素，例如我们常用的一些用于组件和组件之前网络连接的库，HttpClient, OkHttp, gRPC 等。
处理元素是指对数据进行转化的元素，例如 HTTP 服务器 (Apache, Nginx), 网关，代理，浏览器等。
软件架构本身是对系统运行时的一种抽象。一方面，系统存在多个层次的抽象，每层都有自己的架构，另一方面，系统又由多个操作阶段构成，每个阶段都有自己的架构。
那么，什么是多个层次的抽象呢？例如，你的公司有一款面向用户的移动应用。从上层的抽象来看，这款应用由客户端及服务端构成。在这一层次上，处理元素有客户端，服务端，连接元素是用于在客户端与服务器传送数据的组件，数据元素即是在客户端与服务端之间传递的信息。
如果你把抽象层次下降一点，就能在整个系统中发现更多的架构元素。例如，把客户端抽象层次下降一些，会发现客户端有 Android 和 iOS 之分。
同理，服务端将抽象层次再下降一点，就能识别出更多的处理元素，例如，用于负载均衡的处理元素。
从上面的例子可以看出，从不同的抽象层次观察，可以得到不同的架构。另一方面，对同一系统而言，在不同操作阶段，也有不同的架构，这是什么意思呢？
对一个系统而言，都有初始化，提供服务，停止等阶段。在不同阶段，都有着不同的数据元素，处理元素。
例如，在初始化阶段，如果我们使用了 Spring Framework, 那么 Spring 框架会根据我们的配置，生成各种对象，这时候，数据元素是我们的配置，处理元素是 Spring 框架。但是到了服务阶段，各种用于处理的元素已经生成，配置已经不再是此时的数据元素，因为他们已经内化到处理元素中了。此时的数据元素，有从客户端发来的请求中的数据，有我们服务端的业务数据。此时的处理元素，是服务端的各种模块，例如用于搜索的模块，用于渲染的模块。
软件架构配置
从上一节我们了解到，软件架构由数据元素，连接元素，处理元素构成。但是我们描述一个软件架构时，除了描述软件架构由什么元素组成，还需要描述这些元素之间的关系。软件架构配置(Configurations)，就是用于描述系统运行时，数据元素，连接元素和处理元素之间关系的概念。那么，这种 “关系” 又是指什么呢？我们可以将其理解为对元素之间的一种约束。
软件架构属性
我们设计软件架构时，在选择了数据元素，连接元素，处理元素，并且确定了他们之间的关系后，系统就会体现出一系列性质。这些性质，就是软件架构属性。
软件架构属性包括功能属性和非功能属性。功能属性表示系统是否完成了需要的功能，而非功能属性则代表了系统除了完成功能之外，还具有的一些性质，例如可扩展性，可重用性等等。
软件架构风格
一个软件架构由不同元素构成，元素之间有各种各样的约束，而软件架构风格就是指一组协作的架构约束。有了架构风格的概念，我们就可以方便地比较不同的软件架构。当我们谈到某个系统是某种架构风格时，就代表了这个系统的架构背后有一系列架构约束。
说了这么多概念，他们之间到底有什么关系呢？对我们设计系统又有什么用呢？里面有一条重要的逻辑链条，就是系统需求，约束与属性之间的关系。我们设计任何一个系统，都是要满足特定的需求，除了特定功能需求之外，有的系统需要满足高性能，有的系统需要满足高可用，有的系统需要经常进行灵活的扩展。那么，怎么设计系统才能达到这种需求呢？ 那就是对系统进行一些特定的约束。特定的约束会导致特定的属性，特定的属性又会满足特定的需求。
因此，架构风格，即一组约束，导致了一组架构属性，这组架构属性构成了系统需求的一个超集。
所以，要设计好系统，就要正确地识别出，系统到底需要满足哪些需求，当需求不能都满足时，优先满足哪些。然后要了解如何对系统进行划分，如何确定组件之间的关系，有哪些约束的手段，这些约束，又会导致哪些属性。这也是论文后面会仔细探讨的问题。
总的来说，从抽象的角度看，架构风格是对架构的一种抽象，一种架构风格对应多种架构。而架构本身是对系统的抽象，同一架构对应着多种不同的系统。而这篇论文，主要探讨的，就是基于网络的应用架构以及架构风格。
基于网络的应用架构
这一节介绍基于网络的应用架构，主要解决三个问题：
基于网络的应用架构是指什么
如何评估基于网络的应用架构
基于网络的应用架构中，重要的架构属性有哪些
什么是基于网络的应用架构
之前，我们已经介绍了软件架构的概念，基于网络的应用架构是在软件架构的基础上，施加了一个约束，即组件之间的通信限于消息传递。论文中，还特别说明了基于网络的应用和分布式系统的区别。一般而言，我们在使用分布式系统时，就像使用一个集中式的系统一样，网络的存在对用户来说是透明的。而基于网络的应用，“网络”的存在无需表现为对用户透明的形式，有时候还要用户感知到“网络”的存在，特别是“网络”意味着一定的性能开销时。
如何评估基于网络的应用架构
那么，我们如何评估基于网络的应用架构呢？就是从根本上讲，评估一个应用架构，就不看这个架构是否满足了系统的需求。之前我们讲系统属性的时候说过，系统属性分功能属性和非功能属性。相应地，这里看架构是否满足系统的需求，也要看是否满足了功能需求，是否满足了非功能需求。功能需求和我们的业务相关，而非功能需求，就要使用架构风格来评估。
我们知道，架构风格代表了一组架构约束，用架构风格评估架构，就是看这种约束，是否能使系统的需求得到满足。
在上图中，我们的系统有一组架构约束，分别是
同时，我们还有一组系统需要的属性，即系统的需求，分别是
每种架构约束，会在不同程度上影响某种属性。这样，我们知道了系统的架构风格之后，就能评估架构是否满足了系统的需求。
基于网络的应用架构中的重要属性
下面，我们就介绍在基于网络的应用架构中，重要的属性有哪些，这也是我们在设计系统时，要思考，我们的系统，最终要满足哪些属性。如果我们连有哪些属性都不知道，又怎么设计一个系统？
这里主要包括的属性有：性能，可伸缩性，简单性，可修改性，可见性，可移植性，可靠性。注意，我们这里谈论这些属性性，关注的点，都在 “基于网络” 的环境下。
性能(Performance)
我们首先要讲的一个系统属性，就是性能。我们常说“性能优化”，那么，我们到底在优化什么？性能本身又由什么决定？
ACM Queue 上有一篇文章，，里面提到，多数时候，我们提到性能时，指的都是计算机软件完成某种任务所需要的时间，也有的时候，性能是指“吞吐”，即一定时间间隔内，完成的任务数。这和我们常说的，“响应时间”， “QPS” 等是一致的。这里，我们先讲性能的决定因素有哪些，然后再讲性能度量问题。
性能的决定因素，主要有下面几个方面：
每个组件的实现
决定性能的，首先是应用的需求。假如，你的应用是用来下载数据的，看视频的，还是实时交易的？不用类型的应用，能达到的性能水平是不一样的，比较不同类型应用的性能指标，也是没有什么意义的。此外，决定性能的还有交互风格，你的系统中，组件之间的通信是基于 TCP 还是 UDP，达到的性能水平也会有所不同。另外，架构的设计也影响系统的性能，例如子系统是如何划分的，连接元素用的什么，有没有使用缓存，组件之间数据传输的格式是什么，这些都会对系统性能造成影响。最后，组件的实现也会影响性能，即使你什么都设计好了，一个糟糕的实现，还是会对性能造成致使打击。
接下来，我们讲如何度量性能，我们谈性能时，通常谈到的就是各种性能指标，这些指标就是通过不同形式的度量得到的。在基于网络的环境下，对性能的度量主要分三个方面：
用户可察觉性能
网络使用效率
对网络性能的度量也分为多种。吞吐是指组件之间信息转移的速率；负载(overhead) 是指跨网络传输带来的某种额外的负担，这种“负担”可能是时间，也可能是内存，带宽等等，负载又分初始负载每次交互的负载，在组件之间通讯时，我们要确定，通讯是每次都要建立连接，再传输数据么，还是只建立一次连接，后面的多次传输可以复用这个连接；带宽是指特定网络上最大吞吐量；可用带宽是指真正可以被系统使用的那部分带宽。
用户可察觉的性能，又分为两个方面，一是延迟，即初次请求到首次响应的时间，二是完成时间，即完成一个应用动作所需要的时间。我们看下 Chrome 对一次网络请求时间的划分就能明白这个概念：
从 Queueing 到 Wariting(TTFB) 即是初次请求到首次响应的时间，其中 TTFB 的含义就是 (Time to first byte)，即首字节响应时间。而完成时间，要等到 Content Download，即所有内容下载完成后，才结束。区分延迟和完成时间是很重要的，在其它条件都相同的条件下，页面是等到所有元素下载完成后，用户才能看到内容并且交互，还是下载部分内容后，用户就可以看到并交互了。这两种形式对用户而言是完全不同的感受，虽然他们的完成时间相同。
关于网络使用效率，作者给我们的忠告是
最佳的应用性能是通过不使用网络而获得的
这就告诉我们，能不使用网络的时候，就不要使用网络。知乎上有一个问题，”大公司里怎样开发和部署前端代码？”, 其中张云龙讲的 前端静态资源部署方案 就是对如何减少网络使用最好的解读。从最初没有缓存(每次请求都要通过网络获取数据)，到使用 304 协商缓存(通过网络询问内容是否有变化，没变化就不需要下载资源)，再到使用内容摘要精确控制缓存（无需通过网络询问资源是否有变化），步步减少对网络的使用，从而提高了性能，有兴趣可以移步。
另外，在服务端的设计中，我们常会使用 Redis 来作缓存，提高数据访问速度，但是我们也要想下，如果数据可以放在本地内存中，是不是可以减少对网络的使用，从而提高系统的性能和稳定性呢？
性能的问题，是个很宏大的问题，在今后的博文中，我们会专门讨论这个话题。
可伸缩性(Scalability)
可伸缩性是指架构支持大量组件或者大量的组件之间交互的能力。例如，我们的系统用于处理客户端的请求。当请求量太大，系统支持不了如此大量的请求时，通常我们会如何做呢？一般通过水平扩展或者垂直扩展的方式，提高系统的处理能力。水平扩展，就是通过增加服务实例个数的方式提升处理能力，垂直扩展通过增加单个实例可以使用的资源提升系统的处理能力，例如增加 CPU 核数，增加内存，增加存储空间，机械硬盘换 SSD等方式。
系统的可伸缩性就是指，我们是否可以很容易地通过水平扩展或者垂直扩展，增加系统的处理能力。例如，如果我们可以很容易地提高单核 CPU 的性能（垂直扩展），那对我们多核的需求也就没那么强烈了，现实是单核 CPU 性能很难再提高，所以现在已经是多核时代，人们也越来越重视系统的并发能力(水平扩展）。又例如，现在大量使用的各种 NoSQL 数据库，其中很重要的原因之一，就是水平扩展性，单个数据库实例的处理能力毕竟有限，如果能很方便地通过加数据库实例的方式增加系统的处理能力，那系统的可伸缩性就比较强。
简单性是指系统是否正确地使用了分离关注点的原则，对功能进行了划分，使得每个组件都足够简单。简单的组件容易被理解和实现，因此简单性对系统设计而言，是非常重要的。
可修改性是指对应用架构所作的修改的难易程度。可修改性进一步可以划分成可进化性，可扩展性，可定制性，可配置性和可重用性。总的来说，可修改性就是指系统应对变化的能力。当新需求出现，或者现在的系统已经不适合当前的场景时，我们是不是可以通过简单地调整系统，使得系统满足当前的需求。
先谈可扩展性。现在的 IDE, 无论是 Jetbrains 系列，还是 Eclipse，还是有宇宙第一 IDE 之称的 Visual Studio，都提供了插件机制，方便地对系统的功能进行扩展（可扩展性）。又比如著名的 Nginx, 其本身提供了一个稳定的核心，同时我们可以按规范为其开发第三方模块，扩展 Nginx 的能力，本来这种机制就增强了 Nginx 的可扩展性，但是因为 Nginx 第三方模块需要用 C 编写的，对很多人而言，开发效率不高，因此 agentzh（章亦春）的
项目受到广泛的欢迎，OpenResty 把 Nginx 与 LuaJIT 结合，即保留了 Nginx 的高性能，又可以方便地使用 Lua 开发自己的应用，可以说进一步提升了系统的可扩展性。但是这还不够，春哥准备在 OpenResty 之上，再定义一个小语言 EdgeLang, 这是一种基于规则的语言，用它写的代码，经过编译，可以生成高效的 OpenResty Lua 代码，可以说进一步降低了对 Nginx 进行扩展的难度。
其次是可定制性。例如 Java 9 中将出现的模块化功能，Jigsaw。有了模块化，我们就可以根据自己的需要对 JDK 进行细粒度的定制和裁剪，从而可以按需部署，不必将 JDK/JRE 中不需要的东西也部署到生产环境。
再次是可配置性，系统可以正常运行起来后，一些需要经常修改的东西，是写死在了代码里，还是可以很方便地进行配置，配置之后，系统可以自动检测到变化，并加载生效，还是需要重启系统？这些都反映可配置性的高低。
最后是可重用性。例如我们写了个负载均衡器，这个负载均衡器是否与上下游的组件耦合在一起了？是不是可以很方便地用到其它上下游组件的环境中？如果可以在很多其它场景中使用，那重用性就好，如果和特定的上下游组件有强耦合，那重用性就差。
可见性是指一个组件对于其它两个组件之间的交互进行监视或者仲裁的能力。例如在一个分布式的系统中，可能有大量组件存在，如果设计架构时，没考虑可见性，那系统一旦出了问题，查起来就比较困难。
例如，Google 的论文
出现后，就出现一系列用于分布式系统跟踪的开源项目。例如 ,
从上图可以看出，用 Pinpoint 我们可以观察分布式系统中，组件之间的交互情况，这就使得系统的可见性大大增强。
增强系统可见性，不仅能在系统出现问题时，快速定位系统瓶颈。也能在问题出现之初就感知到故障，而不是等到某一天突然发现某个系统已经不能正常服务，而我们却不知道。
如果软件能在不同的环境下运行，那软件就是可移植的。
例如，Java 平台的应用，由虚拟机屏蔽了底层系统的细节，因此可以比较容易地在不同系统之间移植。这样你就不必在多个平台，编写多套代码了。
在设计系统时，我们就需要考虑系统的可移植性，例如移动端应用，是不是可以方便地在 iOS 和 Android 之间移植，服务端应用，是不是可以方便地移植到云端环境？ 如果系统的实现，对特定环境的依赖比较重，那移植起来就不大容易。
可靠性是指当组件，连接器或数据中出现部分故障时，一个架构容易受到系统层面故障影响的程度。
例如，系统中如果一个组件出现了故障，整个系统都被拖垮了，那这个系统的可靠性就比较差，如果系统有良好的降级策略，在部分组件故障时，仍然可以保证系统核心部分正常运转，那系统的可靠性就比较好。这提示我们设计组件时，要避免由于自身故障，对外界造成大的影响，同时也要减少其它组件出现故障时，自己受到影响的程度，尽力提高整个系统的可靠性。
又例如，如果系统设计成一个单点，能服务一旦挂了，就无法正常提供服务了，这样可靠性就比较差。如果提供了足够的冗余，一个节点挂掉，其它节点还能提供服务，这样可靠性就比较好。
基于网络的架构风格
这一章主要解决的问题有
什么是架构风格
不同架构风格对系统属性有什么影响
什么是架构风格
架构风格就是将一组架构约束组合起来，再给它一个名字。向一种架构风格添加一个约束，就形成了一种新的架构风格。
上图是各种架构上的约束，组合起来就组成了架构风格。
我们学习架构风格，其实就是要了解各种架构约束，了解他们会带来什么，他们组合起来又意味着什么。
基于网络的架构风格
其中网络的架构风格，主要有下面这些，他们都是各种架构约束的组合。
数据流风格
移动代码风格
点对点风格
每种风格又可以细分出一些风格。
数据流风格
数据流风格分为下面两个风格：
管道和过滤器(Pipe and Filter, PF)
统一管道和过滤器(Uniform Pipe and Filter, UPF)
管道和过滤器风格，在输入端读取数据流，在输出端产生数据流，架构上的约束为组件之间要零耦合，不能共享状态。统一管道和过滤器风格在此基础上，增加了一个约束，即所有组件使用统一的接口。
我们可以看到很多数据流风格的例子。例如，UNIX/LINUX 中的 shell, 命令和命令之间可以任意组合，原因就是命令之间的接口是统一的标准输入输出，数据就可以在任意组合的命令之间流动，从而根据我们的需求，随时组合成各种各样的功能。
又例如，著名的编译器工具链 LLVM。
源代码经过编译器前端，优化器，编译器后端，最终形成机器码。LLVM 有一套自己的代码表示方式，称为 LLVM IR。在 LLVM 内部，组件之间以 LLVM IR 作为接口统一的方式。编译器前端将源代码生成 LLVM IR, 优化器将 LLVM IR 转化成优化后的 LLVM IR，编译器后端将 LLVM IR 转化成机器码。
这样做编译器前端的人，可以专注于将各种语言转化成 LLVM IR，不必关心怎么优化，怎么生成各类平台上的机器码。做编译器优化的人，可以专注于优化 LLVM IR，不必关心前端和后端，多个优化器之间也可以组合。做编译器后端的人可以专注由将 LLVM 转化成各类平台的机器码。
通过这些例子，我们可以明白数据流风格的好处，这种风格简化了系统的设计，各个组件之间以统一的方式通信，同时可扩展性，可进化性很好，想加个功能，或者替换某个功能，只需要新加一个组件，或者优化其中一个组件就可以了，其它组件不受到影响。每个组件在这个过程中，可重用性也得到极大提高。
但数据流风格也有缺点，例如组件太多，会影响整个系统性能，要统一接口，需要转化数据格式，也会影响系统性能。
复制风格又分为下面两种风格：
复制仓库(Replicated Repository, RR)
缓存(Cache, $)
所谓复制仓库风格，就是通过多个进程提供相同的服务。我们对这种方式应该很熟悉，通过这种方式，整个系统可以处理更多请求，可伸缩性得到提高；每个进程压力的减少，也可以降低响应时间；同时因为存在冗余，系统也变得更可靠。
缓存风格，就是复制之前请求的结果，下次再有请求时，直接返回之前缓存的结果。这也是比较常见的设计，例如浏览器的缓存，文件系统的缓存。采用缓存风格，对性能有改善，但是改善程度也受到缓存命中率的影响，因而改善程度不如复制仓库风格；对网络的使用效率也有提升，因为结果直接缓存了，不必穿过网络，经过各种计算生成；
分层风格有很多变种，但最基本的就是 客户-服务器 风格，在这种风格的基础上，再逐渐施加其它约束，形成新的风格。
分层风格分为下面的几个风格：
客户-服务器(CS)
分层与分层-客户-服务器(LCS)
客户-无状态-服务器(CSS)
客户-缓存-无状态-服务器(C$SS)
分层-客户-缓存-无状态-服务器(LC$SS)
远程会话(RS)
客户-服务器风格中，客户端通过连接器将请求发到服务器要求提供服务，而服务器提供一组服务，并监听对这些服务的请求。客户-服务器风格背后的原则是分离关注点，客户端关注用户接口，服务端关注业务逻辑的处理，数据的生成。两端分离后，可以各自独立地演化。我们可以关注一下前后端分离的一些实践，来理解分离关注点原则对互联网开发模式的改变。
在分层风格中，系统按层次来组织，每一层为上层提供服务，并使用下层的服务。典型的例子就是 TCP/IP 协议栈。
我们可以看出，分层之后，每一层只和其上层下层有耦合，减少了跨层的耦合。应用层的协议不必关心低层的数据链路层，各层都在自己的抽象层次上工作。不同的应用层可以复用下层的协议，可重用性得到提高。但分层系统会降低系统的性能，各层会有自己的数据格式，数据格式的层层转换会带来一定开销。分层-客户-服务器风格，是在客户-服务器的基础上添加了代理(proxy) 和网关(gateway) 组件。
无状态-客户-服务器风格，是在客户-服务器风格基础上添加了无状态这一约束。无状态的意思就是客户端与服务端的会话状态，不能在服务端保存。我们举个移动广告平台跟踪广告展示，点击的例子，来说明有状态的设计与无状态的设计的区别。
客户端向服务端请求广告，服务端除了返回广告内容外，还需要返回展示上报和点击上报跟踪链接，当广告有展示时，客户端会访问展示上报链接，服务端收到上报后，对展示进行计数，点击上报也是如此。
我们先来看有状态的设计：
这种设计中，服务端向客户端返回的跟踪链接只有一个 id，值为 123, 与此值相关的上下文信息，例如广告位，请求 ip，时间等信息被存入数据库。当广告有展示时，客户端上跟踪服务上报，参数中即有 id 123， 跟踪服务收到请求时，从数据库中提取出与 123 相关的上下文信息，之后进入统计流程。
这种设计就是一种有状态的设计，此处的状态就是指 id 123 的上下文信息，可以看出他们被保存在服务端。这种设计的好处是，跟踪链接会比较短，因而网络上传输的数据会少。坏处有很多，一是系统的伸缩性变差，因为广告上下文信息要在服务端存储，并且在有展示时提取出来，当请求量变大，展示周期变大时，需要存储的数据量都会被放大。二是系统的可靠性变差，因为不是请求的广告都会有展示，请求的上下文信息不可能永远存在服务端，总有过期时间，但是如果过期之后，展示上报到达跟踪服务，就会提取不到之前的状态信息。三是可见性下降，如果展示跟踪失效，可能是客户端出问题，也可能数据库里没数据了，数据没存进去，数据过期，出了问题会很难查。
我们再看来无状态的设计。
无状态的设计中，与展示/点击相关的上下文信息，直接放在跟踪链接中。有展示时，上报的链接中就包含了与此展示相关的所有信息。好处就是系统伸缩性提高，因为展示相关的状态不需要在服务端保存了，分散到了客户端；同时可靠性也得到提高，因为状态无需维护；另外，可见性也得到提高，因为展示相关的信息都在跟踪链接里了，直接观察是否上报了正确的链接就可以分析展示上报情况。坏处就是如果展示相关信息很多，链接会很长，在网络上传输的数据会变多，也可能会被截断。
当然，有状态的设计自然有它的用处，但是不在上面我们举例的那类场景。这就是我们要讲的远程会话风格。
远程会话风格是客户-服务器风格的变体，客户端在服务器启动会话，而应用的状态完全保留在服务器上。这样的好处是，客户端的设计可以得到很大简化，可重用性得到提高。而系统功能的扩展性也得到提高，因为升级服务端后，所有客户端可以同时受益，想想升级客户端与服务端的难度就可以明白这一点就多方便。当然，坏处就是因为服务端要保存客户端状态，降低了伸缩性。
移动代码风格
移动代码风格使用移动性(mobility)来动态地改变处理过程与数据源之间的距离。主要有下面几种风格：
虚拟机(VM)
远程求值(REV)
按需代码(COD)
虚拟机风格应该是我们比较熟悉的，例如常用的 Java 语言运行在虚拟机上，虚拟机分离了指令与实现，可移植性比较好，因为虚拟机本身帮我们屏蔽了底层系统的细节，另外扩展性也比较好，例如 Java 虚拟机有了 G1 垃圾收集器后，所有平台上的 Java 代码均可同时受益。
远程求值风格适用的场景是客户端知道如何执行服务，但是缺少执行服务的资源，此时，客户端可以将代码发送到服务端，服务端组件执行完后，将结果返回客户端。例如，我们用 Spark Shell 对大规模的数据作交互式的分析时，数据和计算资源都不在本地，但是客户端知道分析机群上的哪些数据，知道如何分析，代码会被发到 Spark 集群上，对数据进行分析，分析结果最后又返回 Spark Shell。
按需代码风格中，客户端知道如何访问资源，但是不知道如何处理资源，此时客户端可以向远程服务器请求处理资源的代码，在本地执行。典型的例子就是 JavaScript，浏览器从服务器上下载 JS 代码，在浏览器中执行。这种方式的好处是，能够方便地为已经部署的客户端添加功能，改善了可扩展性。我们想添加新功能时，升级 JS 代码就可以了，浏览器下载了新版本的 JS 代码，就能使用新功能了。
点对点风格
点对点风格要介绍的一种风格叫 基于事件的集成(EBI)，其含义是一个组件发布一个或者多个事件，其它组件对某类事件进行订阅。
例如，在 Kafka 中，生产者向某个 topic 生产数据，可以有多个消费者消费这个 topic 中的数据。当我们想用这个 topic 中的数据做更多的事情时，只需要新增加一个消费者就可以了。这样，系统的扩展性就很好。同时消费者可以独立地演化，而不会影响其它消费者。想象一下，如果你把这些消费者的功能集中在某一个系统中，那每次添加功能，都要改这个系统，同时如果某个功能对资源的消耗比较大，因为其它功能和这个功能在同一系统中，就会对其它功能造成影响。
到这里，我们对各种架构风格的介绍就结束了。
设计 Web 架构
Roy Fielding 博士在定义了架构属性，架构约束，架构风格之后，用这些理论去指导 Web 架构的设计。
之前已经说过，Web 规模开始扩大后，现有架构的缺陷已经不能支持这么大的规模，需要对其进行增强，摆在眼前的任务有：
定义在现有的早期 Web 架构中被公共地、一致地实现的架构通信的子集
识别出在这个架构中存在的问题
定义标准解决问题: URI, HTTP, HTML
架构风格就被用于解决这些问题，首先架构风格被用于描述现有 Web 架构背后的基本原理，包括分离关注点，简单性，通用性等。然后通过为架构风格添加约束，使其满足现代 Web 架构所需要的属性。在修改 Web 架构时，要与新 Web 架构风格进行比较分析，以便在新提议部署前识别出其与 Web 架构风格的冲突。
表述性状态转移(REST)
在介绍完各种约束，架构风格后，REST 架构风格就变得水到渠成了。它是通过在一个空风格基础上，不断添加约束而形成的。
从空风格开始，先后添加下面的约束：
客户-服务器
之前我们已经讲了这些约束对系统设计而言意味着什么。
最后用两张图总结一下 REST 架构风格推导中的约束与属性的关系。
上图可以看出，在 REST 架构推荐过程中，添加的各种约束。
上图可以看出，各种约束为系统带来的各种特性。
文章到这里就全部结束了，这篇文章主要结合 Roy Fielding 博士论文的前三章介绍了基于风格的应用架构设计中，需要关注的架构属性，架构约束，以及架构风格。有些内容基于经验所限，可能无法做到表达精确，希望以后能不断修改，补充。
没有更多推荐了，