架构_架构师 - CSDN
架构 订阅
架构,又名软件架构,是有关软件整体结构与组件的抽象描述,用于指导大型软件系统各个方面的设计。架构描述语言(ADL)用于描述软件的体系架构。现在已有多种架构描述语言,如Wright(由卡内基梅隆大学开发),Acme(由卡内基梅隆大学开发),C2(由UCI开发),Darwin(由伦敦帝国学院开发)。ADL的基本构成包括组件、连接器和配置。 [1] 展开全文
架构,又名软件架构,是有关软件整体结构与组件的抽象描述,用于指导大型软件系统各个方面的设计。架构描述语言(ADL)用于描述软件的体系架构。现在已有多种架构描述语言,如Wright(由卡内基梅隆大学开发),Acme(由卡内基梅隆大学开发),C2(由UCI开发),Darwin(由伦敦帝国学院开发)。ADL的基本构成包括组件、连接器和配置。 [1]
信息
外文名
Software architecture
别    称
软件架构
中文名
架构
架构特性
架构是对存储在Active Directory中的对象类别和属性的描述。对于每一个对象类别来说,该架构定义了对象类必须具有的属性,它也可以有附加的属性,并且该对象可以是它的父对象。可以动态更新的Active Directory 架构。应用程序可以使用新的属性和类扩展该架构,并能立刻使用该扩展。通过在Active Directory 中创建或修改存储在 Active Directory 中的架构对象来完成架构的更新。与Active Directory 中的所有对象一样,架构对象能访问控制列表,因此只有授权的用户才可以更改架构。
收起全文
精华内容
参与话题
  • 架构师成长之路(3)--如何成为架构师(方法)

    万次阅读 多人点赞 2015-10-26 17:18:00
    如果我们要成为架构师,我们自己要面临的三大问题: 找准自己定位:我是谁?在哪里? 怎样做好架构师:我要做什么? 如何搭建架构师知识体系:我该怎么做? 这里面就是做事方法论:目标(我要做什么),方法(计划)...

    前言:

    哲学家常思考的问题:" 我是谁?"" 我从哪里来?"" 要到哪里去?不只是哲学家,我想每个人都有自己对这三个问题的认知。
    如果我们要成为架构师,我们自己要面临的三大问题:
    找准自己定位:我是谁?在哪里?
    怎样做好架构师:我要做什么?
    如何搭建架构师知识体系:我该怎么做?
    这里面就是做事方法论:目标(我要做什么),方法(计划)(我该怎么做),  执行/行动
    
    

    0.能力等级定义


    心理学家德雷福斯经过了大量的调查研究,将人分成了五个等级,构建了“德雷福斯等级模型”。五个等级分别为:新手、进阶新手、胜任者、精熟者以及专家。简单列举一下每个等级的特点,方便我们定位自己在哪个等级。参考《卓越密码:如何成为专家》。

    1、新手:新手一般是初入职场1~3年的员工。他们的特点是严格遵照规定,不会有太多自己的想法,因此不会出大的错误也不会有太大的成绩。

    2、进阶新手:工作几年后,新手开始学会细分任务,慢慢地对工作有了自己的想法。这个时候,已经能达到进阶新手的阶段。

    3、胜任者:第三个阶段是胜任者。胜任者顾名思义,在工作岗位上能够保质保量地完成任务,而且能够制定计划和按情况处理任务。

    4、精熟者:与胜任者相比,精熟者开始能发现工作中出现的问题,并对问题有着自己的思考。此时,精熟者开始建立了自己工作的大局观和整体观,处理问题的时候也更加灵活。

    5、专家:最后一个阶段就是专家,专家的过人之处在于其“无招胜有招”。因为专家工作已经不需要具体的方法和规则,他们的工作就是从现在已有的工作方式中去探寻更个性化、有创造力的解决问题的方法。

     

    我们研发人员发展的技术路径(仅供参考):

     

    一、初级工程师

       具备技能:学习的知识是语言基础、计算机基础理论、网络基础,操作系统等相关基础知识等,应该在大学完成。 依靠指令清单,必须按部就班。

       知识能力:入门了解。知道概念。对全局性、体系性的东西没兴趣。需要有人指导才能干活。但可以靠着百度解决具体的小问题。

    二、中级工程师

       成长阶段:一般工作一年后。

       具备能力:能够独立解决各种各样的领域内问题。

       知识能力:熟练掌握语言工具,技术过硬。

    三、高级/资深工程师(管理自己):

        成长阶段:工作3-5年后,熟悉分布式系统、高性能系统搭建。精通某种开发语言,掌握架构设计能力和业务理解能力。熟练掌握各种设计模式以及具备一定运维能力。
        技术能力:
              1、负责核心复杂功能的实现方案设计、编码实现  。
              2、负责疑难BUG分析诊断、攻关解决

        知识能力:精通语言工具。技术精湛,技术高超、博学多识, 精益求精。

    、资深工程师:

          高级工程师是在技术深度上精通,资深需要在广度上扩大知识面,熟悉多种开发语言。同时具备团队管理经验。
          具备独立设计一个业务模块的能力,并且能够独立设计数据库表以及UML画图,利用部分设计模式以及懂得算法和效率的高质量代码。

    五、技术经理/研发Leader(管理一个团队)

         成长阶段:技术经理本身就是从资深工程师发展而来,很多公司的技术经理根本没有从一线研发做起,大部分就是一个项目经理,带带项目为主,根本无法胜任真正意义上的“技术经理”的工作。
         具备能力:
          1、技术能力:
           1)首先需要具备核心模块代码编程的能力,从设计方案到核心编码,再到后期的代码review,这方面是要能完全胜任的,能识别开发风险。
           2)代码模板研发与推广、最佳实践规范总结与推广、自动化研发生产工具研发与推广
         2、团队管理能力:
           任务管理:开发工作量评估、开发任务分配,
           团队效率:能够帮助团队人员提升能力,以及推动更加合理的考核机制。
           团队专业力:招聘面试、新人指导、领导复盘总结改进
         3、综合能力(沟通协调)能力:此外,还需要具备协调的能力,以及与人打交道的能力。与平级部门、产品、设计、测试、运营打交道的能力。

    五、架构师(专注某个平台的技术架构规划)

    成长阶段:
    能称得上“架构师”的,工作年限至少也要在5至8年以上,具体还要看个人的学习能力、领悟能力和成长速度。
    之所以有架构师这个称谓,主要是由于公司发展壮大之后,需要专注于技术的人才做专业的事;所以,架构师也可以理解为技术专家,以攻克公司技术难题为主。
    需要分离管理族和专业族。整个研发团队可能已经超过100来人了,需要有人专注来做架构规划、设计、日常维护。不能让研发总监和研发Leader又做管理又做技术一股脑都扔给他们。
    具备能力:
    1、架构分析:从功能性需求中识别出需要增加的非功能性需求,好满足性能、可扩展、解耦/集成、安全、可运维、高可用、易部署、易更新。并且识别完非功能型需求,还要做技术选型、技术架构风险识别、技术实现工作量评估
    2、架构设计与实现:非功能性模块的架构设计、接口设计、代码实现。所以需要的是有代码实现能力还要有架构思维的工程师,不需要画PPT的工程师
    3、业务架构设计与实现:需要对跨系统的接口进行识别、实现、维护,需要对能写成公共代码类库的进行分析、识别、接口设计、实现、变更维护。
    4、重构:架构师需要经常做Bug分析、非模板性和公共类库代码检查,以发现代码腐烂程度,以发现还有哪些代码没有做很好的架构与精心的代码设计。所以重构是经常性维护发生的,不是攒到某一刻动大手术,甚至推翻重做,那就不叫重构了。

     

    五、技术总监(管理多个团队leader):

         成长阶段:一般需要工作8至10年以上,首先,技术经理的工作能够做的非常好,再加上公司的发展需要,需要能够同时带领多条业务线或者多个团队共同协作的时候,基本就是技术总监了。
    从管理的层级,技术总监同时管理多个技术经理,管理从业务线划分的团队。
    从技术的层级,能胜任架构师这个级别,也就是技术专家。
         具备能力:
        1、从业务线和团队的角度,需要具备组建研发部、搭建公共技术平台、方便上面各条产品线开发。
        2、通过技术平台、通过高一层的职权,管理和协调各个产品线组。现在每个产品线都应该有合格的研发Leader和高级程序员了。

    五、CTO (软件产品和技术是统一管理的.是商业、产品、技术、管理、团队相平衡的综合统管)。

    成长阶段:CTO的要求是最高的,不是每一个人都胜任CTO,好的CTO在国内非常少,非常稀有。
    可能不少同学会认为CTO只是专注于技术,或者进入一些小公司,挂职某某CTO就认为达到了这个级别,其实这是错误的。
    CTO是一个系统的成长轨迹,不是一朝一夕可以练成的,需要后天的巨大“自我改进”能力。
    CTO,是集软件、产品、技术、管理等诸多能力为一体的,CTO做的事情,是商业、产品、技术、管理、团队相平衡的综合统管。

    具备能力:
    1、业绩达成:洞察客户需求,捕捉商业机会,规划技术产品,通过技术产品领导业务增长,有清晰的战略规划、主攻方向,带领团队实现组织目标
    2、前沿与平台:到这个研发规模规模级别了,一定要有专门的团队做技术应用创新探索和前沿技术预研。而且要和技术平台团队、应用研发团队形成很好的联动作用,让创新原型试点能够很平滑的融入商业平台再让应用研发线规模化的使用起来。大量的前沿探索都死在了内部,做完试点就停滞了,这就需要CTO做好整体的衔接推动工作。
    3、研发过程管理:站在全局立场来端到端改进业务流程,为业务增长提供方便
    4、组织与人才建设:公司文化和价值观的传承;研发专业族团队梯队建制建设、研发管理族团队梯队建制建设;创建创新激发机制,激发研发人创新向前发展,激发黑马人脱颖而出

     

           软件架构师的正式成型在于机遇、个人努力和天赋 软件构架师其实是一种职位,但一个 程序员在充分掌握软构架师所需的基本技能后,如何得到这样的机会、如何利用所掌握的技能进行应用的合理构架、如何不断的抽象和归纳自己的构架模式、如何深入行业成为能够胜任分析、构架为

    一体的精英人才这可不是每个人都能够遇上的馅饼。

    我们找好路径以后,看看我们如何做?  《卓越密码:如何成为专家》这本书里面,介绍的方法是:
    学习能力:确定方向目标,选择高质量学习内容、学习元认知,持续精进学习。
    不断实践:实践检验理论,解决问题,总结提炼。
    思维能力:擅长思考、深度思考:学会归纳、概括,概念,推理。掌握结构化、抽象、系统性、框架等思维。

     

     

    1、走正确的路:高效地学习


      如果想成为一个架构师,就必须走正确的路,否则离目标越来越远,正在辛苦工作的程序员们,你们有没有下面几种感觉?

         一、我的工作就是按时完成领导交给我的任务,至于代码写的怎样,知道有改进空间,但没时间去改进,关键是领导也不给时间啊。

         二、我发现我的水平总是跟不上技术的进步,有太多想学的东西要学,Jquery用的人最近比较多啊,听说最近MVC比较火,还有LINQ,听说微软又有Silverlight了……

         三、  我发现虽然我工作几年了,除了不停的coding,Ctrl+c和Ctrl+V更熟练了,但编码水平并没有提高,还是一个普通程序员,但有人已经做到架构师了。

         四、工作好几年了,想跳槽换个工作,结果面试的考官都问了一些什么数据结构,什么垃圾回收,什么设计模式之类的东西,虽然看过,但是平时用不着,看了也忘记了,回答不上来,结果考官说我基础太差。。。

    有没有,如果没有,接下来就不用看了,你一定是大拿了,或者已经明白其中之道了,呵呵。

    如果有,恭喜你,你进入学习误区了,如果想在技术上前进的话,就不能一直的coding,为了完成需求而工作,必须在coding的同时,让我们的思维,水平也在不停的提高。

     

    写代码要经历下面几个阶段:

    一 、你必须学习面向对象的基础知识,如果连这个都忘了,那你的编程之路注定是在做原始初级的重复!

        很多程序员都知道类、方法、抽象类、接口等概念,但是为什么要面向对象,好处在哪里,要解决什么问题?只是明白概念,就是表达不清楚,然后在实际工作中也用不上,过了一段时间,面向对象的东西又模糊了,结果是大多数程序员用着面向对象的语言做着面向过程的工作,因此要学习面向对象,首先应该明白面向对象的目的是什么?

    面向对象的目的是什么?

         开发语言在不断发展,从机器语言,到汇编,到高级语言,再到第四代语言;软件开发方法在不断发展,从面向过程,面向对象,到面向方面等。虽然这些都在不断发展,但其所追求的目标却一直没变,这些目标就是:
       1.降低软件开发的复杂度
       2.提高软件开发的效率
       3.提高软件质量:可维护性,可扩展性,可重用性等。

         其中语言的发展,开发方法的发展在1,2两条上面取得了极大的进步,但对于第3条,我们不能光指望开发方法本身来解决。

    提高软件质量:可维护性,可扩展性,可重用性等,再具体点,就是高内聚、低耦合,面向对象就是为了解决第3条的问题。因此要成为一个好的程序员,最绕不开的就是面向对象了。

     

    二、 要想学好面向对象,就必须学习设计模式。

         假定我们了解了面向对象的目的,概念了,但是我们coding过程中却发现,我们的面向对象的知识似乎一直派不上用场,其实道理很简单,是因为我们不知道怎么去用,就像游泳一样,我们已经明白了游泳的好处,以及游泳的几种姿势,狗刨、仰泳、蛙泳、自由泳,但是我们依然不会游泳。。。。

    因此有了这些基本原则是不行的,我们必须有一些更细的原则去知道我们的设计,这就有了更基础的面向对象的五大原则,而把这几种原则更详细的应用到实际中来,解决实际的问题,这就是设计模式,因此要学好OO,必须要学习设计模式,学习设计模式,按大师的话说,就是在人类努力解决的许多领域的成功方案都来源于各种模式,教育的一个重要目标就是把知识的模式一代一代传下去。

         因此学习设计模式,就像我们在看世界顶级的游泳比赛,我们为之疯狂,为之着迷。

     

    三 学习设计模式

         正像我们并不想只是看别人表演,我们要自己学会游泳,这才是我们的目的所在。

    当我们看完几篇设计模式后,我们为之精神振奋,在新的coding的时候,我们总是想努力的用上学到的设计模式,但是经常在误用模式,折腾半天发现是在脱裤子抓痒。。。

    当学完设计模式之后,我们又很困惑,感觉这些模式简直太像了,很多时候我们分不清这些模式之间到底有什么区别,而且明白了设计过程中的一个致命的东西--过度设计,因为设计模式要求我们高扩展性,高重用性,但是在需求提出之初,我们都不是神,除了依靠过去的经验来判断外,我们不知道哪些地方要扩展,哪些地方要重用,而且过去的经验就一定是正确的吗?所以我们甚至不敢再轻易用设计模式,而是还一直在用面向过程的方法在实现需求。

     

    四 学习重构

     

         精彩的代码是怎么想出来的,比看到精彩的代码更加令人期待,于是我们开始思考,这些大师们莫非不用工作,需求来了没有领导规定完成时间,只以设计精彩的代码为标准来开展工作?这样的工作太爽了,也不可能,老板不愿意啊。就算这些理想的条件他都有,他就一开始就设计出完美的代码来了?也不可能啊,除非他是神,一开始就预料到未来的所有需求,那既然这些条件都没有,他们如何写出的精彩代码?

        Joshua Kerievsky在那篇著名的《模式与XP》〔收录于《极限编程研究》一书)中明白地指出:在设计前期使用模式常常导致过度工程(over-engineering)。这是一个残酷的现实,单凭对完美的追求无法写出实用的代码,而「实用」是软件压倒一切的要素。

         在《重构-改善既有的代码的设计》一书中提到,通过重构(refactoring),你可以找出改变的平衡点。你会发现所谓设计不再是一切动作的前提,而是在整个开发过程中逐渐浮现出来。在系统构筑过程中,你可以学习如何强化设计;其间带来的互动可以让一个程序在开发过程中持续保有良好的设计。

        总结起来就是说,我们在设计前期就使用设计模式,往往导致设计过度,因此应该在整个开发过程,整个需求变更过程中不断的重构现在的代码,才能让程序一直保持良好的设计,由此可见,开发过程中需要一直重构,否则无论当初设计多么的好,随着需求的改变,都会变成一堆烂代码,难以维护,难以扩展。所谓重构是这样一个过程:「在不改变代码外在行为的前提下,对代码做出修改,以改进程序的内部结构」。重构的目标,就是设计模式,更本质的讲就是使程序的架构更趋合理,从而提高软件的可维护性,可扩展性,可重用性。

    《重构-改善既有的代码的设计》一书也是Martin Fowler等大师的作品,软件工程领域的超级经典巨著,与另一巨著《设计模式》并称"软工双雄",不可不读啊。

     

    五 开始通往优秀软件设计师的路上

    通过设计模式和重构,我们的所学和我们工作的coding终于结合上了,我们可以在工作中用面向对象的思维去考虑问题,并开始学习重构了,这就像游泳一样,我们看完了各种顶级的游泳比赛,明白各种规则,名人使用的方法和技巧,现在是时候回家去村旁边的小河里练练了,练习也是需要有教练的,推荐另一本经典书叫《重构与模式》,引用他开篇的介绍,本书开创性地深入揭示了重构与模式这两种软件开发关键技术之间的联系,说明了通过重构实现模式改善既有的设计,往往优于在新的设计早期使用模式。本书不仅展示了一种应用模式和重构的创新方法,而且有助于读者结合实战深入理解重构和模式。

    这本书正是我们需要的教练,值得一读。

     

    六 没有终点,只有坚持不懈的专研和努力。

          经过了几年的坚持,终于学会了灵活的运用各种模式,我们不需要去刻意的想用什么模式,怎么重构。程序的目标,就是可维护性,可扩展性,可重用性,都已经成了一种编程习惯,一种思维习惯,就像我们联系了几年游泳之后,我们不用再刻意的去考虑,如何让自己能在水上漂起来,仰泳和蛙泳的区别..... 而是跳进水里,就自然的游了起来,朝对岸游去。但是要和大师比起来,嘿嘿,我们还有很长的路要走,最终也可能成不了大师,但无论能不能成为大师,我们已经走在了成为大师的正确的路上,我们和别的程序员已经开始不一样,因为他们无论再过多少年,他们的水平不会变,只是在重复造轮子,唯一比你快的,就是ctrl+c和ctrl+v。

    正确的路上,只要坚持,就离目标越来越近,未来就一定会是一个优秀的架构师,和优秀架构师的区别,可能只是时间问题。

     

     

     

    2、大牛的法宝:不断实践总结


         原文:http://www.cnblogs.com/seesea125/archive/2012/03/30/2425281.html

         接下来我们就要往这个方向努力。然而如唐僧去西天取经一样,要历经种种磨难,一路上打败各种妖魔鬼怪才能继续前行,所以唐僧取经,第一件事,就是招徒弟,遇见妖魔鬼怪就让技术高超的徒弟打败它,徒弟不听话就念紧箍咒,徒弟也搞不定的妖怪,就请观音菩萨搞定,这就是唐僧成功的法宝,没法宝上路,看来我们会死的比较惨啊,哈哈。

        我们在通往架构师的路上,同样会遇到各种各样的问题,但不幸的是,没有菩萨在暗中相助,要是有牛人相助你,那老兄你太幸运了,成功几率大大增加。但我们没有牛人帮助,更没有技术高超的徒弟一路保驾护航,关键招徒弟得开工资啊,我们还穷的自己还养不活呢,怎么办呢?干脆自己动手,找几件护身法宝,留着路上除妖之用。

        问题是从哪找呢?百思不得其解,俗话说思索不如搜索,干脆百度一把,看看牛人都是怎么炼成的,找来找去,还真总结出几个牛人身上的通用法宝,当然独门绝技之类的就不拿了,太多那不动,呵呵。拿着这些法宝上路,嘿嘿,那我们就不是骑着白龙马去西天了,我们骑着摩托去西天,那速度可要快多了。

     

    法宝一:牛人爱惜自己的时间。

        时间就是金钱,时间就是生命,时间如同健康一样,如果时间都没有,那成功也就是浮云了。所以牛人总是很爱惜自己的时间,总是在想办法提高自己的做事效率。我突然想了起来,我QQ里有几个牛人,问问他们点经验,结果大大出乎意料,个个不在线,好不容易发现个牛人在线,当然关系还不错的,至少不会不给面子吧?于是就QQ说一句客气话,“老兄,好久不见啊,最近在忙什么呢?”,消息发出去石沉大海,到第二天上QQ才收到一句回复,“不好意思,昨忙,有事直接打电话”,言简意赅,效率奇高,再想想我们这些普通人的时间真多,一聊天就是半天,搞不好还有N个QQ群在不停的弹窗……

        偶然看到一本书,《时间管理:小强升职记》,顺便打开看下,第一句话这么说的,“前一种人用20%的时间完成了后一种人用80%的时间才能完成的事情,因此前一种人忙着考虑如何打发闲暇时间,后一种人则忙着煮方便面和熬夜。

        假设上面说的真的,我初略算了算,如果一天工作时间8个小时,则牛人的效率,可能就1,2个小时就干完了,这么一算,牛人忙和一年,则等于普通人忙和了4,5年啊!法宝,这绝对是牛人致胜的第一大法宝,俗话说,唯有以快制慢,方能笑傲江湖,没错,东方不败牛就牛在,速度快,快到你还没出招就搞定你了。强大啊,这个法宝一定要随身携带,哈哈。

        所以看了这本书后,我做的第一件事就是QQ关了,动不动就一闪一闪的,思路一直被打断,这不是在浪费自己最大的资本--时间吗?关了几天,发现效率果然出奇的高多了,QQ真是害人不浅啊,当然爱惜时间,还有很多经验,建议有空看看相关的书,受益不浅啊,嘿嘿。 

     

    法宝二:牛人善于总结

         算了算我记得的牛人,包括古代的,孔子,老子,孙子,曹雪芹,鲁迅。。。我想了一下,为什么能记住他们呢,几千年前来,轰动一时的人物应该年年有,代代有,但我们为什么只记住了这些人?很容易想明白了,他们有个共同的特征,就是总结自己的思想,写成了书,并把这种思想传承了下来,而那些身怀绝技但是秘而不传,或者只传近亲的绝技,都在历史的长河中慢慢消失了。

        再看看IT界的,苏杰,写了本《人人都是产品经理》,程杰,写了本《大话设计模式》......,除了写之外,他们还经常出没于各大论坛,讲座,想躲也躲不开啊......。

        看来牛人之所以牛,自己懂的多是一个因素之外,更重要的是把自己的知识总结下来,并努力推广了。

        所以日常总结,随身笔记一定是要做的,总结就是理解它,并且理解了还不要忘记它,时不时还翻回来看看,否则很多知识学习了又忘记了。总结这个法宝,一定要随身携带。 

     

    法宝三:牛人懂得专注

        有句古语是这么说的:能够到达金字塔顶端的动物只有两种,一种是苍鹰,一种是蜗牛。苍鹰之所以能够到达是因为它们拥有傲人的翅膀;而慢吞吞的蜗牛能够爬上去就是认准了自己的方向,并且一直沿着这个方向努力。对人类而言,能够于众生中脱颖而出者实属少数,这些人也可以看到:一种是资质优越、天生异禀,本就是成就大事的种子,这样的人是少之又少,而且有些这样的人还因不知学习而沦落了;另外一种人就是蜗牛一样的人物了,早早就知道自己是常人,却仍然立下鸿鹄之志,凭借后天的坚忍和努力,同样做出常人难以想象的成就。它是一种素质,更是一种能力。

        IT领域需要懂的太多了,运维、DBA,各种操作系统,各种语言......如果什么都想学好,结果必然是什么都略懂,但什么都拿不出手,所以注定无所建树,成不了牛人,而牛人是深刻明白这个道理,所以他们会选择某一点最感兴趣的地方,然后持之以恒的深专下去,最后达到了别人从未达到的高度,我们做IT编程的大部分人都是这也学那也学,简历上写的什么都是精通,其实这样的人,却不敢深问,深问了什么都不懂,因此专注某一个技术领域,是走向成功的铁定法则。

     

    法宝四:牛人注重动手能力

        “纸上得来终觉浅,绝知此事要躬行”。

        看来牛人并不是坐在屋子里成牛人的,而是在不断的动手,在实战中造就了牛人,也充分的说明了学习的终极目的--学以致用。所以我们学习时,一定要动手做,只学习不动手,是成不了牛人的啊。

         拿着这四件法宝去取经,就为成功增加了强有力的保障,并能达到事半功倍的效果。当然在路上多捡几件随身携带,那功力就会更强了,像007一样,口袋里总是需要什么有什么。法宝之重要,犹如练武的找到了降龙十八掌,乾坤大挪移之类的秘籍一样,拿到手了就会成为武林至尊!

     

     

    3、架构师都要懂哪些知识


    Web架构师究竟都要学些什么?具备哪些能力呢?先网上查查架构师的大概的定义,参见架构师修炼之道这篇文章,写的还不错,再查查公司招聘Web架构师的要求。 总结起来大概有下面几点技能要求:

    一、 架构师有优秀的编码能力,解决开发人员无法解决的难题。

    二、 架构师对系统的大数据容量高性能高并发高容错的网站有架构设计和开发经验。

    三、 架构师对操作系统、数据库、服务器各种软件使用的配置比较了解,比如Linux、Web负载均衡、反向代理、数据库集群、容灾等比较了解。

    四、 架构师对软件开发过程有清晰明确的认识,也就是对软件工程有有明确的认识,并能把需求进行分析、建模。

    五、 架构师学习能力很强、接触知识面要很宽广、喜欢关注和接触各种新的技术。

    六、 架构师沟通能力很强。

    七、 架构师对从事的行业的业务要有深刻的了解。

     

    换个角度看看这些要求把:

    第一条要求你是个优秀的程序员。

    第二、第三条要求你要懂DBA,运维都需要懂的知识。

    第四条要求你是个项目经理。

    第五条要求你是个技术全才,不仅学的要深,还要学的广。

    第六条、第七条要求你熟悉公司业务人员、产品人员要懂的知识。

    这个要求太高了,架构师就相当于战争中的司令员的位置,是整个团队的核心和灵魂,这种技术要求甚至技术总监和CEO都不具备,唯一要求少点的就是管理能力,如果再具备管理能力,那就甚至能超过技术总监和CTO了,而中国不乏管理人才,怪不得有人总结说,中国没有合格的架构师呢,也难怪,大概算一算,这种要求相当于一个人学6个人的知识,并且都能达到专业的水平,这就意味着你的领悟能力和学习能力,要高于常人几倍!所以说,成为架构师确实需要天分啊。

     

    成为优秀程序员,需要学好的知识:

    1、 面向对象编程、UML画图、设计模式、代码重构

    2、 常用ORM工具

    3、  MVC,WCF,XMl, JQuery ,SQL以及性能优化

    4、 FrameWork一些深入的知识

    5、 高性能代码,比如静态化,MemCached等手段。

    6、 最好也了解一些其他语言,比如Java,PHP等。

     

    成为DBA,需要学好的知识:

    1、 常用数据库,MSSQL、MySQL、Oracle,性能调优熟练,备份、负载均衡、集群、容灾熟练

    2、 大数据量处理熟练

    3、 各种数据库监控软件

     

    成为运维,需要学好的知识:

    1、 各种Web负载均衡的硬件,比如F5,软件,比如Nginx等原理和配置

    2、 反向代理加速,比如SquID等

    3、 操作系统,Linux是必须懂的,各种好的工具都在Linux下。

    4、 各种性能监控软件。

     

    成为产品和业务以及项目经理,需要学好的知识:

    1、 沟通和理解能力。

    2、 该行业和本公司的业务逻辑。

    3、 软件工程的知识。

    4、 质量控制、进度控制、人员组织等。

     

    看来想成为合格的Web架构师,需要学太多东西了,只有一条路可走--持续不断的修炼和学习。

    另外学习中,采用先深后广的策略是明智的选择,一门学深了,其他知识可能都会融会贯通,那样比较的学起来会很快。否则可能陷入知识的海洋里,没准淹死了。

    总体的看来,Web架构,分为服务器架构和程序架构两个方面的架构,一般的Web架构师还是偏向程序架构,因此学好语言,程序架构是基础,学好了这些,做一个合格的架构师没大问题,毕竟DBA,运维的东西在公司都有专业的人在干。

    所以深度还是要深入学习编程的知识、软件架构知识,有了这个基础后,Web架构师应该在大数据量、高并发、高负载、以及高容错方向再有所了解和涉及,再返过来促进我们对软件架构的思考,这种深-广-深-广的模式是我们学习的方法,只要坚持不懈努力几年,做真正合格的Web架构师是没大问题的。

    另外由于学东西太多,在学习中也要和其他架构师多交流、共同进步,多参考其他架构师的杰作,是很明智的选择。

     

    原文地址:http://www.cnblogs.com/seesea125/archive/2012/03/30/2425281.html

    对原文一些内容做一些修改,感谢作者,尊重原著。

     

     

     

     

     

    展开全文
  • 软件架构详解(附图)

    万次阅读 多人点赞 2016-05-24 15:31:21
    软件架构(software architecture) 软件架构(software architecture)是一系列相关的抽象模式,用于指导大型软件系统各个方面的设计。软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。...


    软件架构(software architecture)

    软件架构(software architecture)是一系列相关的抽象模式,用于指导大型软件系统各个方面的设计。软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段,这些抽象组件被细化为实际的组件,比如具体某个类或者对象。在面向对象领域中,组件之间的连接通常用接口_(计算机科学)来实现。

    软件体系结构是构建计算机软件实践的基础。与建筑师设定建筑项目的设计原则和目标,作为绘图员画图的基础一样,一个软件架构师或者系统架构师陈述软件构架以作为满足不同客户需求的实际系统设计方案的基础。从和目的、主题、材料和结构的联系上来说,软件架构可以和建筑物的架构相比拟。一个软件架构师需要有广泛的软件理论知识和相应的经验来实施和管理软件产品的高级设计。软件架构师定义和设计软件的模块化,模块之间的交互,用户界面风格,对外接口方法,创新的设计特性,以及高层事物的对象操作、逻辑和流程。



    架构是在组件,彼此间和与环境间的关系,引导设计发展原则中体现的系统的基本结构。

    软件体系结构是构建计算机软件实践的基础。与建筑师设定建筑项目的设计原则和目标,作为绘图员画图的基础一样,一个软件架构师或者系统架构师陈述软件构架以作为满足不同客户需求的实际系统设计方案的基础。

    软件构架是一个容易理解的概念,多数工程师(尤其是经验不多的工程师)会从直觉上来认识它,但要给出精确的定义很困难。特别是,很难明确地区分设计和构架:构架属于设计的一方面,它集中于某些具体的特征。

    软件架构是指在一定的设计原则基础上,从不同角度对组成系统的各部分进行搭配和安排,形成系统的多个结构而组成架构,它包括该系统的各个组件,组件的外部可见属性及组件之间的相互关系。组件的外部可见属性是指其他组件对该组件所做的假设。

    在“软件构架简介”中,David GArlan和 Mary Shaw认为软件构架是有关如下问题的设计层次:“在计算的算法和数据结构之外,设计并确定系统整体结构成为了新的问题。结构问题包括总体组织结构和全局控制结构;通信、同步和数据访问的协议;设计元素的功能分配;物理分布;设计元素的组成;定标与性能;备选设计的选择。”

    但构架不仅是结构;IEEEWorking Group on Architecture 把其定义为“系统在其环境中的最高层概念”。构架还包括“符合”系统完整性、经济约束条件、审美需求和样式。它并不仅注重对内部的考虑,而且还在系统的用户环境和开发环境中对系统进行整体考虑,即同时注重对外部的考虑。

    在 Rational Unified ProcESs 中,软件系统的构架(在某一给定点)是指系统重要构件的组织或结构,这些重要构件通过接口与不断减小的构件与接口所组成的构件进行交互。

    从和目的、主题、材料和结构的联系上来说,软件架构可以和建筑物的架构相比拟。一个软件架构师需要有广泛的软件理论知识和相应的经验来实施和管理软件产品的高级设计。软件架构师定义和设计软件的模块化,模块之间的交互,用户界面风格,对外接口方法,创新的设计特性,以及高层事物的对象操作、逻辑和流程。

    一般而言,软件系统的架构(ArchitECture)有两个要素:

    1.它是一个软件系统从整体到部分的最高层次的划分。

    2.一个系统通常是由元件组成的,而这些元件如何形成、相互之间如何发生作用,则是关于这个系统本身结构的重要信息。

    详细地说,就是要包括架构元件(Architecture Component)、联结器(Connector)、任务流(TASk-flow)。所谓架构元素,也就是组成系统的核心"砖瓦",而联结器则描述这些元件之间通讯的路径、通讯的机制、通讯的预期结果,任务流则描述系统如何使用这些元件和联结器完成某一项需求。

    建造一个系统所作出的最高层次的、以后难以更改的,商业的和技术的决定。

    在建造一个系统之前会有很多的重要决定需要事先作出,而一旦系统开始进行详细设计甚至建造,这些决定就很难更改甚至无法更改。显然,这样的决定必定是有关系统设计成败的最重要决定,必须经过非常慎重的研究和考察。

     


    根据我们关注的角度不同,可以将架构分成三种:

    1.逻辑架构

    软件系统中元件之间的关系,比如用户界面,数据库,外部系统接口,商业逻辑元件,等等。

    从上面这张图中可以看出,此系统被划分成三个逻辑层次,即表象层次,商业层次和数据持久层次。每一个层次都含有多个逻辑元件。比如WEB服务器层次中有HTML服务元件、Session服务元件、安全服务元件、系统管理元件等。

    2.物理架构

    软件元件是怎样放到硬件上的。

    比如下面这张物理架构图,图中所有的元件都是物理设备,包括网络分流器、代理服务器、WEB服务器、应用服务器、报表服务器、整合服务器、存储服务器、主机等等。

    3.系统架构

    系统的非功能性特征,如可扩展性、可靠性、强壮性、灵活性、性能等。

    系统架构的设计要求架构师具备软件和硬件的功能和性能的过硬知识,这一工作无疑是架构设计工作中最为困难的工作。

    此外,从每一个角度上看,都可以看到架构的两要素:元件划分和设计决定。

    首先,一个软件系统中的元件首先是逻辑元件。这些逻辑元件如何放到硬件上,以及这些元件如何为整个系统的可扩展性、可靠性、强壮性、灵活性、性能等做出贡献,是非常重要的信息。

    其次,进行软件设计需要做出的决定中,必然会包括逻辑结构、物理结构,以及它们如何影响到系统的所有非功能性特征。这些决定中会有很多是一旦作出,就很难更改的。

    根据作者的经验,一个基于数据库的系统架构,有多少个数据表,就会有多少页的架构设计文档。比如一个中等的数据库应用系统通常含有一百个左右的数据表,这样的一个系统设计通常需要有一百页左右的架构设计文档。

     

    我们决定以多种构架视图来表示软件构架。每种构架视图针对于开发流程中的涉众(例如最终用户、设计人员、管理人员、系统工程师、维护人员等)所关注的特定方面。

    构架视图显示了软件构架如何分解为构件,以及构件如何由连接器连接来产生有用的形式 [PW92],由此记录主要的结构设计决策。这些设计决策必须基于需求以及功能、补充和其他方面的约束。而这些决策又会在较低层次上为需求和将来的设计决策施加进一步的约束。

    构架由许多不同的构架视图来表示,这些视图本质上是以图形方式来摘要说明“在构架方面具有重要意义”的模型元素。在 Rational Unified Process 中,您将从一个典型的视图集开始,该视图集称为“4+1 视图模型”[KRU95]。它包括:

    1.用例视图:包括用例和场景,这些用例和场景包括在构架方面具有重要意义的行为、类或技术风险。它是用例模型的子集。

    2.逻辑视图:包括最重要的设计类、从这些设计类到包和子系统的组织形式,以及从这些包和子系统到层的组织形式。它还包括一些用例实现。它是设计模型的子集。

    3.实施视图:包括实施模型及其从模块到包和层的组织形式的概览。 同时还描述了将逻辑视图中的包和类向实施视图中的包和模块分配的情况。它是实施模型的子集。

    4.进程视图:包括所涉及任务(进程和线程)的描述,它们的交互和配置,以及将设计对象和类向任务的分配情况。只有在系统具有很高程度的并行时,才需要该视图。在 Rational Unified Process 中,它是设计模型的子集。

    5.部署视图:包括对最典型的平台配置的各种物理节点的描述以及将任务(来自进程视图)向物理节点分配的情况。只有在分布式系统中才需要该视图。它是部署模型的一个子集。构架视图记录在软件构架文档中。您可以构建其他视图来表达需要特别关注的不同方面:用户界面视图、安全视图、数据视图等等。对于简单系统,可以省略 4+1 视图模型中的一些视图。

     

    早在1960年代,诸如E·W·戴克斯特拉就已经涉及软件架构这个概念了。自1990年代以来,部分由于在 Rational Software Corporation 和Microsoft内部的相关活动,软件架构这个概念开始越来越流行起来。

    卡内基梅隆大学和加州大学埃尔文分校在这个领域作了很多研究。卡内基·梅隆大学的Mary Shaw和David Garlan于1996年写了一本叫做 Software Architecture perspective on an emerging DIscipline的书,提出了软件架构中的很多概念,例如软件组件、连接器、风格等等。加州大学埃尔文分校的软件研究院所做的工作则主要集中于架构风格、架构描述语言以及动态架构。

    计算机软件的历史开始于五十年代,历史非常短暂,而相比之下建筑工程则从石器时代就开始了,人类在几千年的建筑设计实践中积累了大量的经验和教训。建筑设计基本上包含两点,一是建筑风格,二是建筑模式。独特的建筑风格和恰当选择的建筑模式,可以使得一个建筑独一无二。

    软件与人类的关系是架构师必须面对的核心问题,也是自从软件进入历史舞台之后就出现的问题。与此类似地,自从有了建筑以来,建筑与人类的关系就一直是建筑设计师必须面对的核心问题。英国首相丘吉尔说,我们构造建筑物,然后建筑物构造我们(We shape our buildings, and afterwaRDS our buildings shape us)。英国下议院的会议厅较狭窄,无法使所有的下议院议员面向同一个方向入座,而必须分成两侧入座。丘吉尔认为,议员们入座的时候自然会选择与自己政见相同的人同时入座,而这就是英国政党制的起源。Party这个词的原意就是"方"、"面"。政党起源的关键就是建筑物对人的影响。

    在软件设计界曾经有很多人认为功能是最为重要的,形式必须服从功能。与此类似地,在建筑学界,现代主义建筑流派的开创人之一Louis Sullivan也认为形式应当服从于功能(FORMs follows function)。

    几乎所有的软件设计理念都可以在浩如烟海的建筑学历史中找到更为遥远的历史回响。最为著名的,当然就是模式理论和XP理论。

    正如同软件本身有其要达到的目标一样,架构设计要达到的目标是什么呢?一般而言,软件架构设计要达到如下的目标:

    1.可靠性(Reliable)。软件系统对于用户的商业经营和管理来说极为重要,因此软件系统必须非常可靠。

    2.安全性(Secure)。软件系统所承担的交易的商业价值极高,系统的安全性非常重要。

    3.可扩展性(SCAlable)。软件必须能够在用户的使用率、用户的数目增加很快的情况下,保持合理的性能。只有这样,才能适应用户的市场扩展得可能性。

    4.可定制化(CuSTomizable)。同样的一套软件,可以根据客户群的不同和市场需求的变化进行调整。

    5.可扩展性(Extensible)。在新技术出现的时候,一个软件系统应当允许导入新技术,从而对现有系统进行功能和性能的扩展。

    6.可维护性(MAIntainable)。软件系统的维护包括两方面,一是排除现有的错误,二是将新的软件需求反映到现有系统中去。一个易于维护系统可以有效地降低技术支持的花费。

    7.客户体验(Customer Experience)。软件系统必须易于使用。

    8.市场时机(Time to Market)。软件用户要面临同业竞争,软件提供商也要面临同业竞争。以最快的速度争夺市场先机非常重要。

     



    虽然以上视图可以表示系统的整体设计,但构架只同以下几个具体方面相关:

    模型的结构,即组织模式,例如分层。基本元素,即关键用例、主类、常用机制等,它们与模型中的各元素相对。几个关键场景,它们表示了整个系统的主要控制流程。记录模块度、可选特征、产品线状况的服务。

    构架视图在本质上是整体设计的抽象或简化,它们通过舍弃具体细节来突出重要的特征。在考虑以下方面时,这些特征非常重要。

    系统演进,即进入下一个开发周期。在产品线环境下复用构架或构架的一部分。评估补充质量,例如性能、可用性、可移植性和安全性。向团队或分包商分配开发工作。决定是否包括市售构件。插入范围更广的系统。

     


    构架模式是解决复杂构架问题的现成形式。构架框架或构架基础设施(中间件)是可以在其上构建某种构架的构件集。许多主要的构架困难应在框架或基础设施中进行解决,而且通常针对于特定的领域:命令和控制、MIS、控制系统等等。

    构架模式示例

    [BUS96] 根据构架模式最适用的系统的特征将其分类,其中一个类别处理更普遍的结构问题。下表显示了 [BUS96] 中所提供的类别和这些类别所包含的模式。

    类别 模式结构 层管道和过滤器黑板分布式系统代理交互系统 模型-视图-控制器表示-抽象-控制自适应系统反射微核

    在“软件构架简介”中,David Garlan 和 Mary Shaw 认为软件构架是有关如下问题的设计层次:“在计算的算法和数据结构之外,设计并确定系统整体结构成为了新的问题。结构问题包括总体组织结构和全局控制结构;通信、同步和数据访问的协议;设计元素的功能分配;物理分布;设计元素的组成;定标与性能;备选设计的选择。”[GS93]

    但构架不仅是结构;IEEE Working Group on Architecture 把其定义为“系统在其环境中的最高层概念”[IEEE98]。构架还包括“符合”系统完整性、经济约束条件、审美需求和样式。它并不仅注重对内部的考虑,而且还在系统的用户环境和开发环境中对系统进行整体考虑,即同时注重对外部的考虑。

    在Rational Unified Process 中,软件系统的构架(在某一给定点)是指系统重要构件的组织或结构,这些重要构件通过接口与不断减小的构件与接口所组成的构件进行交互。

    为阐明其含义,下面将详述其中的两个;完整说明请参见 [BUS96]。模式以下列广泛使用的形式来表示:

    模式名环境问题影响,描述应考虑的不同问题方面解决方案基本原理结果环境示例模式名层

    环境需要进行结构分解的大系统。

    问题必须处理不同抽象层次的问题的系统。例如:硬件控制问题、常见服务问题和针对于不同领域的问题。最好不要编写垂直构件来处理所有抽象层次的问题。否则要在不同的构件中多次处理相同的问题(可能会不一致)。

    影响

    系统的某些部分应当是可替换的构件中的变化不应波动相似的责任应归为一组构件大小 -- 复杂构件可能要进行分解解决办法将系统分成构件组,并使构件组形成层叠结构。使上层只使用下层(决不使用上层)提供的服务。尽量不使用非紧邻下层提供的服务(不跳层使用服务,除非中间层只添加通过构件)。

    示例:

    1. 通用层

    严格的分层构架规定设计元素(类、构件、包、子系统)只能使用下层提供的服务, 服务可以包括事件处理、错误处理、数据库访问等等。 相对于记录在底层的原始操作系统级调用,它包括更明显的机制。

    2. 业务系统层

    上图显示了另一个分层示例,其中有垂直特定应用层、水平层和基础设施层。注意:此处的目标是采用非常短的业务“烟囱”并实现各种应用程序间的通用性。 否则,就可能有多个人解决同一问题,从而导致潜在的分歧。

    有关该模式的深入讨论,请参见指南:分层。

    模式名黑板

    环境没有解决问题的确定方法(算法)或方法不可行的领域。例如 AI 系统、语音识别和监视系统。

    问题多个问题解决顾问(知识顾问)必须通过协作来解决他们无法单独解决的问题。各顾问的工作结果必须可以供所有其他顾问访问,使他们可以评估自己是否可以参与解决方案的查找并发布其工作结果。

    影响

    知识顾问参与解决问题的顺序不是确定的,这可能取决于问题解决策略

    不同顾问的输入(结果或部分解决方案)可能有不同的表示方式

    各顾问并不直接知道对方的存在,但可以评估对方发布的工作

    解决办法多名知识顾问都可访问一个称为“黑板”的共享数据库。黑板提供监测和更新其内容的接口。控制模块/对象激活遵循某种策略的顾问。激活后,顾问查看黑板,以确定它是否能参与解决问题。如果顾问决定它可以参与,控制对象就可以允许顾问将其部分(或最终)解决方案放置于黑板上。

    示例:

    以上显示了使用 UML 建模的结构或静态视图。 它将成为参数化协作的一部分,然后会绑定到实参上对模式进行实例化。

    构架风格软件构架(或仅是构架视图)可以具有名为构架风格的属性,该属性减少了可选的形式,并使构架具有一定程度的一致性。样式可以通过一组模式或通过选择特定构件或连接器作为基本构件来定义。对给定系统,某些样式可作为构架描述的一部分记录在构架风格指南(Rational Unified Process 中设计指南文档的一部分)中。样式在构架的可理解性与完整性方面起着主要的作用。

    逻辑视图:类图、状态机和对象图。进程视图:类图与对象图(包括任务 - 进程与线程)。实施视图:构件图。部署视图:配置图。

     

    架构描述语言(ADL)用于描述软件的体系架构。已有多种架构描述语言,如Wright (由卡内基梅隆大学开发),Acme (由卡内基梅隆大学开发),C2 (由UCI开发), Darwin (由伦敦帝国学院开发)。ADL的基本构成包括组件、连接器和配置。

     


    构架

    构架视图的图形描述称为构架设计图。对于以上描述的各种视图,设计图由以下统一建模语言图组成 [UML99]:

    1.逻辑视图:类图、状态机和对象图。

    2.进程视图:类图与对象图(包括任务 - 进程与线程)。

    3.实施视图:构件图。

    4.部署视图:配置图。

    5.用例视图:用例图描述用例、主角和普通设计类;顺序图描述设计对象及其协作关系。

    构架设计流程

    在 Rational Unified Process 中,构架主要是分析设计工作流程的结果。当项目再次进行此工作流程时,构架将在一次又一次迭代中不断演化、改进、精炼。由于每次迭代都包括集成和测试,所以在交付产品时,构架就相当强壮了。构架是精化阶段各次迭代的重点,构架的基线通常会在此阶段结束时确定。

    架构师

    软件设计师中有一些技术水平较高、经验较为丰富的人,他们需要承担软件系统的架构设计,也就是需要设计系统的元件如何划分、元件之间如何发生相互作用,以及系统中逻辑的、物理的、系统的重要决定的作出。

    这样的人就是所谓的架构师(Architect)。在很多公司中,架构师不是一个专门的和正式的职务。通常在一个开发小组中,最有经验的程序员会负责一些架构方面的工作。在一个部门中,最有经验的项目经理会负责一些架构方面的工作。

    但是,越来越多的公司体会到架构工作的重要性,并且在不同的组织层次上设置专门的架构师位置,由他们负责不同层次上的逻辑架构、物理架构、系统架构的设计、配置、维护等工作。

     


    软件架构是对软件系统运行时元素的抽象,软件系统可能有很多层抽象,或由多重业务流程所组成,每层抽象或每个业务流程都有自己的软件架构。

    软件架构是平衡的艺术。

    参考:

    http://www.uml.org.cn/zjjs/zjjs-bk.asp

    展开全文
  • 资深架构师谈架构(一):什么是架构

    万次阅读 多人点赞 2018-03-22 10:38:19
    甚至于很多架构师一说架构,就开始谈论什么应用架构、硬件架构、数据架构等等。......本文是漫谈架构专栏的第一篇,作者将会通过类比的方式来介绍什么是架构以及为什么会产生架构。一直以来,在软件行业,对于什么是...

    一直以来,在软件行业,对于什么是架构,都有很多的争论,每个人都有自己的理解。甚至于很多架构师一说架构,就开始谈论什么应用架构、硬件架构、数据架构等等。......

    本文是漫谈架构专栏的第一篇,作者将会通过类比的方式来介绍什么是架构以及为什么会产生架构。

    一直以来,在软件行业,对于什么是架构,都有很多的争论,每个人都有自己的理解。甚至于很多架构师一说架构,就开始谈论什么应用架构、硬件架构、数据架构等等。我曾经也到处寻找过架构的定义,请教过很多人,结果发现,没有大家都认可的定义。套用一句关于big data流行的笑话,放在架构上也适用:事实上,架构在软件发明时的N多年以前,就已经存在了,这个词最早是跟随着建筑出现的。所以,我觉得有必要从源头开始,把架构这个概念先讨论清楚,只有这样,软件行业架构的讨论才有意义。
    什么是架构?架构的英文是Architecture,在Wikipedia上,架构是这样定义的:
    Architecture (Latin architectura, from the Greek ?ρχιτ?κτων arkhitekton"architect", from ?ρχι- "chief" and τ?κτων "builder") is both the process and the product of planning, designing, and constructing buildings and other physical structures。
    从这个定义上看,架构好像是一个过程,也不是很清晰。为了讲清楚这个问题,我们先来看看为什么会产生架构。
    为什么会产生架构?想象一下,在最早期,每个人都完全独立生活,衣、食、住、行等等全部都自己搞定,整个人类都是独立的个体,不相往来。为了解决人类的延续的问题,自然而然就有男女群居出现,这个时候就出现了分工了,男性和女性所做的事情就会有一定的分工,可是人每天生活的基本需求没有发生变化,还是衣食住行等生活必须品。
    但是一旦多人分工配合作为生存的整体,力量就显得强大多了,所以也自然的形成了族群:有些人种田厉害,有些人制作工具厉害,有些地方适合产出粮食,有些地方适合产出棉花等,就自然形成了人的分群,地域的分群。当分工发生后,实际上每个人的生产力都得到了提高,因为做的都是每个人擅长的事情。
    整个人群的生产力和抵抗环境的能力都得到了增强。为什么呢?因为每个人的能力和时间都是有限的,并且因为人的结构的限制,人同时只能专心做好一件事情,这样不得已就导致了分工的产生。既然分工发生了,原来由一个人干生存所必需的所有的事情,就变成了很多不同分工的角色合作完成这些事情,这些人必须要通过某些机制合在一起,让每个人完成生存所必需的事情,这实际上也导致了交易的发生(交易这部分就不在这里展开了,有机会再讨论)。
    在每个人都必须自己完成所有生活必须品的生产的时候,是没有架构的(当然在个人来讲,同一时刻只能做有限的事情,在时间上还是可能会产生架构的)。一旦产生的分工,就把所有的事情,切分成由不同角色的人来完成,最后再通过交易,使得每个个体都拥有生活必须品,而不需要每个个体做所有的事情,只需要每个个体做好自己擅长的事情,并具备一定的交易能力即可。
    这实际上就形成了社会的架构。那么怎么定义架构呢?以上面这个例子为例,把一个整体(完成人类生存的所有工作)切分成不同的部分(分工),由不同角色来完成这些分工,并通过建立不同部分相互沟通的机制,使得这些部分能够有机的结合为一个整体,并完成这个整体所需要的所有活动,这就是架构。由以上的例子,也可以归纳出架构产生的动力:
    1.必须由人执行的工作(不需要人介入,就意味着不需要改造,也就不需要架构了)
    2.每个人的能力有限(每个人都有自己的强项,个人的产出受限于最短板,并且由于人的结构限制,同时只能专注于做好一件事情,比如虽然有两只眼睛,但是只能同时专注于一件事物,有两只手,无法同时做不同的事情。ps. 虽然有少部分人可以左手画圆右手画框,但是不是普遍现象)
    3.每个人的时间有限(为了减少时间的投入,必然会导致把工作分解出去,给擅长于这些工作的角色来完成,见2,从而缩短时间)
    4.人对目标系统有更高的要求(如果满足于现状,也就不需要进行架构了)
    5.目标系统的复杂性使得单个人完成这个系统,满足条件2,3(如果个人就可以完成系统的提高,也不需要别的人参与,也就不需要架构的涉及,只是工匠,并且一般这个工作对时间的要求也不迫切。当足够熟练之后,也会有一定的架构思考,但考虑更多的是如何提高质量,提高个人的时间效率)
    有人可能会挑战说,如果一个人对目标系统进行分解,比如某人建一栋房子,自己采购材料,自己搭建,难道也不算架构嘛?如果对于时间不敏感的话,是会出现这个情况的,但是在这种情况下,并不必然导致架构的发生。如果有足够的自觉,以及足够的熟练的话,也会产生架构的思考,因为这样对于提高生产力是有帮助的,可以缩短建造的时间,并会提高房子的质量。事实上建筑的架构就是在长期进行这些活动后,积累下来的实践。
    当这5个条件同时成立,一定会产生架构。从这个层面上来说,架构是人类发展过程中,由懵懵懂懂的,被动的去认识这个世界,变成主动的去认识,并以更高的效率去改造这个世界的方法。以下我们再拿建筑来举例加强一下理解。
    最开始人类是住在山洞里,住在树上的,主要是为了躲避其他猛兽的攻击,以及减少自然环境的变化,对人类生存的挑战。为了完成这些目标,人类开始学会在平地上用树木和树叶来建立隔离空间的设施,这就是建筑的开始。但是完全隔离也有很多坏处,慢慢就产生了门窗等设施。
    建筑的本质就是从自然环境中,划出一块独占的空间,但是仍然能够通过门窗等和自然环境保持沟通。这个时候架构就已经开始了。对地球上的空间进行切分,并通过门窗,地基等,保持和地球以及空间的有机的沟通。当人类开始学会用火之后,茅棚里面自然而然慢慢就会被切分为两部分,一部分用来烧饭,一部分用来生活。当人的排泄慢慢移入到室内后,洗手间也就慢慢的出现了。这就是建筑内部的空间切分。
    这个时候人们对建筑的需求也就慢慢的越来越多,空间的切分也会变成很多种,组合的方式也会有很多种,比如每个人住的房子,群居所产生的宗教性质的房子,集体活动的房子等等。这个时候人们就开始有意识的去设计房子,架构师就慢慢的出现了。一切都是为了满足人的越来越高的需求,提升质量,减少时间,更有效率的切分空间,并且让空间之间更加有机的进行沟通。这就是建筑的架构以及建筑的架构的演变
    总结一下,什么是架构,就是:
    1.根据要解决的问题,对目标系统的边界进行界定。
    2.并对目标系统按某个原则的进行切分。切分的原则,要便于不同的角色,对切分出来的部分,并行或串行开展工作,一般并行才能减少时间。
    3.并对这些切分出来的部分,设立沟通机制。
    4.根据3,使得这些部分之间能够进行有机的联系,合并组装成为一个整体,完成目标系统的所有工作。

    同样这个思考可以展开到其他的行业,比如企业的架构,国家的架构,组织架构,音乐架构,色彩架构,软件架构等等。套用三国演义的一句话,合久必分,分久必合。架构实际上就是指人们根据自己对世界的认识,为解决某个问题,主动地、有目的地去识别问题,并进行分解、合并,解决这个问题的实践活动。架构的产出物,自然就是对问题的分析,以及解决问题的方案:包括拆分的原则以及理由,沟通合并的原则以及理由,以及拆分,拆分出来的各个部分和合并所对应的角色和所需要的核心能力等。

    展开全文
  • 架构设计——架构知识体系

    万次阅读 多人点赞 2018-08-23 13:45:58
    架构设计——架构知识体系   1、什么是架构架构本质 在软件行业,对于什么是架构,都有很多的争论,每个人都有自己的理解。 此君说的架构和彼君理解的架构未必是一回事。 我们主要针对互联网服server系统...

    架构设计——架构知识体系

     

    1、什么是架构和架构本质


    在软件行业,对于什么是架构,都有很多的争论,每个人都有自己的理解。 此君说的架构和彼君理解的架构未必是一回事。

    我们主要针对互联网服server系统(类似网站)来定义架构:架构是系统的骨架,支撑和链接各个部分,包括组件、连接件、约束规范,以及指导这些内容设计与演化的原理。

    组件:类似应用服务,独立模块、数据库、nginx等等、

    连接件:分布式调用、进程间调用、调用使用http协议还是tcp协议、组件之间的交互关系、

    约束规范: 定规则做限制:例如设计原则、编码规范等等。

    是系统性地思考,权衡利弊之后在现有资源约束下的“最合理决策”,并由它来指导团队中的每个人思想层面上的一致。

    即架构=组件+交互。

    这类似建筑设计规划,城市总体规划等,其实就是架构,只是应用的场景不同。盖一座小房子,可以拍脑袋干起来,但是当你要盖一座大楼,如果没有一个建筑设计规划,可以想象搭理最后是什么样?

    架构的本质就是对系统进行有序化地重构以致符合当前业务的发展,并可以快速扩展。

    那什么样的系统要考虑做架构设计?

    1. 需求相对复杂.

    2. 非功能性需求在整个系统占据重要位置.

    3. 系统生命周期长,有扩展性需求.

    4.系统基于组件或者集成的需要.

    5.业务流程再造的需要.

     

    2、架构分类


    架构可细分为业务架构、应用架构、技术架构, 代码架构, 部署架构,.

    架构设计——架构知识体系

     

    业务架构是战略,应用架构是战术,技术架构是装备。其中应用架构承上启下,一方面承接业务架构的落地,另一方面影响技术选型。

    熟悉业务,形成业务架构,根据业务架构,做出相应的应用架构,最后技术架构落地实施。

    如何针对当前需求,选择合适的应用架构,如何面向未来,保证架构平滑过渡,这个是软件开发者,特别是架构师,都需要深入思考的问题。

    一、业务架构(俯视架构):

    包括业务规划,业务模块、业务流程,对整个系统的业务进行拆分,对领域模型进行设计,把现实的业务转化成抽象对象。

    没有最优的架构,只有最合适的架构,一切系统设计原则都要以解决业务问题为最终目标,脱离实际业务的技术情怀架构往往会给系统带入大坑,任何不基于业务做异想天开的架构都是耍流氓。

    所有问题的前提要搞清楚我们今天面临的业务量有多大,增长走势是什么样,而且解决高并发的过程,一定是一个循序渐进逐步的过程。 合理的架构能够提前预见业务发展1~2年为宜。这样可以付出较为合理的代价换来真正达到技术引领业务成长的效果。

    看看京东业务架构(网上分享图):

    架构设计——架构知识体系

     

    二、应用架构(剖面架构,也叫逻辑架构图):

    硬件到应用的抽象,包括抽象层和编程接口。应用架构和业务架构是相辅相成的关系。业务架构的每一部分都有应用架构。

    类似:

    架构设计——架构知识体系

     

    应用架构:应用作为独立可部署的单元,为系统划分了明确的边界,深刻影响系统功能组织、代码开发、部署和运维等各方面. 应用架构定义系统有哪些应用、以及应用之间如何分工和合作。这里所谓应用就是各个逻辑模块或者子系统。

    应用架构图关键有2点:

    1、职责划分: 明确应用(各个逻辑模块或者子系统)边界

    1)逻辑分层

    2)子系统、模块定义。

    3)关键类。

    2、职责之间的协作:

    1)接口协议:应用对外输出的接口。

    2)协作关系:应用之间的调用关系。

    应用分层有两种方式:

    一种是水平分(横向),按照功能处理顺序划分应用,比如把系统分为web前端/中间服务/后台任务,这是面向业务深度的划分。

    另一种是垂直分(纵向),按照不同的业务类型划分应用,比如进销存系统可以划分为三个独立的应用,这是面向业务广度的划分。

    应用的合反映应用之间如何协作,共同完成复杂的业务case,主要体现在应用之间的通讯机制和数据格式,通讯机制可以是同步调用/异步消息/共享DB访问等,数据格式可以是文本/XML/JSON/二进制等。

    应用的分偏向于业务,反映业务架构,应用的合偏向于技术,影响技术架构。分降低了业务复杂度,系统更有序,合增加了技术复杂度,系统更无序。

    应用架构的本质是通过系统拆分,平衡业务和技术复杂性,保证系统形散神不散。

    系统采用什么样的应用架构,受业务复杂性影响,包括企业发展阶段和业务特点;同时受技术复杂性影响,包括IT技术发展阶段和内部技术人员水平。业务复杂性(包括业务量大)必然带来技术复杂性,应用架构目标是解决业务复杂性的同时,避免技术太复杂,确保业务架构落地。

    三、代码架构(也叫开发架构):

    子系统代码架构主要为开发人员提供切实可行的指导,如果代码架构设计不足,就会造成影响全局的架构设计。比如公司内不同的开发团队使用不同的技术栈或者组件,结果公司整体架构设计就会失控。

    代码架构主要定义:

    一、代码单元:

    1、配置设计

    2、框架、类库。

    二、代码单元组织:

    1、编码规范,编码的惯例。

    2、项目模块划分

    3、顶层文件结构设计,比如mvc设计。

    4、依赖关系

    四、技术架构,也可以叫系统架构

    技术架构:确定组成应用系统的实际运行组件(lvs,nginx,tomcat,php-fpm等),这些运行组件之间的关系,以及部署到硬件的策略。

    技术架构主要考虑系统的非功能性特征,对系统的高可用、高性能、扩展、安全、伸缩性、简洁等做系统级的把握。

    系统架构的设计要求架构师具备软件和硬件的功能和性能的过硬知识,这也是架构设计工作中最为困难的工作。

    架构设计——架构知识体系

     

    五、部署拓扑架构图(实际物理架构图):

    拓扑架构,包括架构部署了几个节点,节点之间的关系,服务器的高可用,网路接口和协议等,决定了应用如何运行,运行的性能,可维护性,可扩展性,是所有架构的基础。这个图主要是运维工程师主要关注的对象。

    架构设计——架构知识体系

     

    3、应用架构


    架构演进路程:

    ->初始阶段:LAMP,部署在一台服务器

    ->应用服务器和数据服务器分离

    ->使用缓存改善性能

    ->使用集群改善并发

    ->数据库地读写分离

    ->使用反向代理和cdn加速

    ->使用分布式文件和分布式数据库

    ->业务拆分

    ->分布式服务

    架构设计——架构知识体系

     

    业务架构是生产力,应用架构是生产关系,技术架构是生产工具。业务架构决定应用架构,应用架构需要适配业务架构,并随着业务架构不断进化,同时应用架构依托技术架构最终落地。

    企业一开始业务比较简单,比如进销存,此时面向内部用户,提供简单的信息管理系统(MIS),支持数据增删改查即可,单体应用可以满足要求。

    随着业务深入,进销存每块业务都变复杂,同时新增客户关系管理,以更好支持营销,业务的深度和广度都增加,这时需要对系统按照业务拆分,变成一个分布式系统。

    更进一步,企业转向互联网+战略,拓展在线交易,线上系统和内部系统业务类似,没必要重做一套,此时把内部系统的逻辑做服务化改造,同时供线上线下系统使用,变成一个简单的SOA架构。

    紧接着业务模式越来越复杂,订单、商品、库存、价格每块玩法都很深入,比如价格区分会员等级,访问渠道(无线还是PC),销售方式(团购还是普通)等,还有大量的价格促销,这些规则很复杂,容易相互冲突,需要把分散到各个业务的价格逻辑进行统一管理,以基础价格服务的方式透明地提供给上层应用,变成一个微内核的SOA架构。

    同时不管是企业内部用户,还是外部顾客所需要的功能,都由很多细分的应用提供支持,需要提供portal,集成相关应用,为不同用户提供统一视图,顶层变成一个AOA的架构(application orientated architecture)。

    4、衡量架构的合理性


    架构为业务服务,没有最优的架构,只有最合适的架构, 架构始终以高效,稳定,安全为目标来衡量其合理性。

    一、稳定性。指标:

    1. 高可用:要尽可能的提高软件的可用性,我想每个操作人都不愿意看到自己的工作无法正常进行。黑盒白盒测试、单元测试、自动化测试、故障注入测试、提高测试覆盖率等方式来一步一步推进。

    二、高效指标:

    1. 文档化:不管是整体还是部分的整个生命周期内都必须做好文档化,变动的来源包括但不限于BUG,需求。

    2. 可扩展:软件的设计秉承着低耦合的理念去做,注意在合理的地方抽象。方便功能更改、新增和运用技术的迭代,并且支持在适时对架构做出重构。

    3. 高复用:为了避免重复劳动,为了降低成本,我们希望能够重用之前的代码、之前的设计。这点对于架构环境的依赖是最大的。

    三、安全指标

    1. 安全:组织的运作过程中产生的数据都是具有商业价值的,保证数据的安全也是刻不容缓的一部分。以免出现XX门之类丑闻。加密、https等为普遍手段

    5、常见架构误区


    误区1——架构专门由架构师来做,业务开发人员无需关注:架构的再好,最终还是需要代码来落地,并且组织越大这个落地的难度越大。不单单是系统架构,每个解决方案每个项目也由自己的架构,如分层、设计模式等。如果每一块砖瓦不够坚固,那么整个系统还是会由崩塌的风险。所谓“千里之堤,溃于蚁穴”。

    误区2——架构师确定了架构蓝图之后任务就结束了:架构不是“空中楼阁”,最终还是要落地的,但是架构师完全不去深入到第一线怎么知道“地”在哪?怎么才能落的稳稳当当。

    误区3——不做出完美的架构设计不开工:世上没有最好架构,只有最合适的架构。我们需要的不是一下子造出一辆汽车,而是从单轮车 --> 自行车 --> 摩托车,最后再到汽车。想象一下2年后才能造出的产品,当初市场还存在吗?

    6、架构知识体系


    架构演进

    • 初始阶段:LAMP,部署在一台服务器
    • 应用服务器和数据服务器分离
    • 使用缓存改善性能
    • 使用集群改善并发
    • 数据库地读写分离
    • 使用反向代理和cdn加速
    • 使用分布式文件和分布式数据库
    • 业务拆分
    • 分布式服务

    架构模式

    • 分层:横向分层:应用层,服务层,数据层
    • 分割:纵向分割:拆分功能和服务
    • 分布式
    • 分布式应用和服务
    • 分布式静态资源
    • 分布式数据和存储
    • 分布式计算
    • 集群:提高并发和可用性
    • 缓存:优化系统性能
    • cdn
    • 方向代理访问资源
    • 本地缓存
    • 分布式缓存
    • 异步:降低系统的耦合性
    • 提供系统的可用性
    • 加快响应速度
    • 冗余:冷备和热备,保证系统的可用性
    • 自动化:发布,测试,部署,监控,报警,失效转移,故障恢复
    • 安全:

    架构核心要素

    • 高性能:网站的灵魂
    • 性能测试
    • 前端优化
    • 应用优化
    • 数据库优化
    • 可用性:保证服务器不宕机,一般通过冗余部署备份服务器来完成
    • 负载均衡
    • 数据备份
    • 自动发布
    • 灰度发布
    • 监控报警
    • 伸缩性:建集群,是否快速应对大规模增长的流量,容易添加新的机器
    • 集群
    • 负载均衡
    • 缓存负载均衡
    • 可扩展性:主要关注功能需求,应对业务的扩展,快速响应业务的变化。是否做法开闭原则,系统耦合依赖
    • 分布式消息
    • 服务化
    • 安全性:网站的各种攻击,各种漏洞是否堵住,架构是否可以做到限流作用,防止ddos攻击。
    • xss攻击
    • sql注入
    • csr攻击
    • web防火墙漏洞
    • 安全漏洞
    • ssl

    7、架构书籍推荐


    1. 《大型网站技术架构:核心原理与案例分析》

    这是比较早,比较系统介绍大型网站技术架构的书,通俗易懂又充满智慧,即便你之前完全没接触过网站开发,通读前几章,也能快速获取到常见的网站技术架构及其应用场景。非常赞。

    2. 《亿级流量网站架构核心技术》

    相比《大型网站技术架构》的高屋建瓴,开涛的这本《亿级流量网站架构核心技术》则落实到细节,网站架构中常见的各种技术,比如缓存、队列、线程池、代理……,统统都讲到了,而且配有核心代码。甚至连 Nginx 的配置都有!

    如果你想在实现大流量网站时找参考技术和代码,这本书最合适啦。

    3. 《架构即未来》

    这是一本“神书”啦,超越具体技术层面,着重剖析架构问题的根源,帮助我们弄清楚应该以何种方式管理、领导、组织和配置团队。

    4. 《分布式服务架构:原理、设计与实战》

    这本书全面介绍了分布式服务架构的原理与设计,并结合作者在实施微服务架构过程中的实践经验,总结了保障线上服务健康、可靠的最佳方案,是一本架构级、实战型的重量级著作。

    5. 《聊聊架构》

    这算是架构方面的一本神书了,从架构的原初谈起,从业务的拆分谈起,谈到架构的目的,架构师的角色,架构师如何将架构落地……强烈推荐。

    不过,对于没有架构实践经验的小伙伴来讲,可能会觉得这本书比较虚,概念多,实战少。但如果你有过一两个项目的架构经验,就会深深认同书中追本溯源探讨的架构理念。

    6. 《软件架构师的12项修炼》

    大多数时候所谓的“技术之玻璃天花板”其实只是缺乏软技能而已。这些技能可以学到,缺乏的知识可以通过决定改变的努力来弥补。

    展开全文
  • 课程主体部分从软件架构体系结构、架构设计、技术体系等角度出发,详细介绍了架构师区别于一般开发人员所需要掌握的架构设计方法论与相关实践,包括架构风格与模式、领域驱动设计、类与框架设计、分布式系统架构设计...
  • 四种核心架构思维

    万次阅读 2019-02-11 11:56:35
    架构的本质是管理复杂性,抽象、分层、分治和演化思维是我们工程师/架构师应对和管理复杂性的四种最基本武器。 最近团队来了一些新人,有些有一定工作经验,是以高级工程师/架构师身份进来的,但我发现他们大部分人...
  • 5种架构视图

    千次阅读 2019-03-06 16:29:37
    在实际工作中,我们经常听到“架构”和“架构师”这样的名词,并不新鲜,但是总让很多刚入门的人感觉很神秘,甚至是高深莫测。很少有人对“架构”有全面的了解和认识能并说清楚架构是什么,更谈不上掌握了。事实上,...
  • 四种软件架构,看看你属于哪个层次 如果一个软件开发人员,不了解软件架构的演进,会制约技术的选型和开发人员的生存、晋升...一、单体架构单体架构比较初级,典型的三级架构,前端(Web/手机端)+中间业务逻辑层+...
  • 软件架构设计---软件架构概述

    万次阅读 2018-09-17 21:25:54
    像学写文章一样,在学会字、词、句之后,就应上升到段落...软件架构的研究内容主要涉及软件架构描述、软件架构设计、软件架构风格、软件架构评价和软件架构的形成方法等。  软件设计人员学习软件架构知识旨在站在...
  • 软件架构架构风格

    万次阅读 2018-08-31 20:08:07
    今天给大家分享一下架构方面的东西。都是一些相对基础的东西,有错误的话请指正。 首先我们来介绍一下什么是架构架构一词来源于建筑,代表系统高层次的一些设计角色。比如建筑领域的一栋大楼的架构,指的就是大楼...
  • 架构设计(1)-谈谈架构

    万次阅读 多人点赞 2017-10-17 11:18:15
    1、什么是架构架构本质 在软件行业,对于什么是架构,都有很多的争论,每个人都有自己的理解。 此君说的架构和彼君理解的架构未必是一回事。因此我们在讨论架构之前,我们先讨论架构的概念定义,概念是人认识这...
  • 软件各种系统架构

    万次阅读 多人点赞 2017-12-08 10:53:44
    发布一企业技术架构图,供大家参考。     该技术架构图是本人根据多年企业技术架构经验而制定,是企业技术的总架构图,希望对CTO们有所借鉴。  简单说明: 1.中间件基础运行环境是经过统一...
  • 一、微服务架构实施的前提 二、微服务实施的三大模式 三、实施微服务架构的优势 (一)、六大技术优势 (二)、业务与组织优势 四、实施微服务面临的挑战 (一)、技术架构的挑战 (二)、研发过程的挑战 ...
  • 一、微服务架构实现需求 二、微服务架构实现技术选型:参考标准的两个维度+微服务实现框架对比 (一)技术选型的两个参考标准 1.核心组件完备性 2.关键要素实现难度 (二)微服务实现框架对比 Spring Boot/...
  • 各种系统架构图与详细说明

    万次阅读 多人点赞 2018-09-15 17:49:59
    共享平台逻辑架构设计 如上图所示为本次共享资源平台逻辑架构图,上图整体展现说明包括以下几个方面: 1 应用系统建设 本次项目的一项重点就是实现原有应用系统的全面升级以及新的应用系统的开发,从而建立...
  • 领域驱动实践总结二:架构分析与代码设计 领域驱动设计DDD是一种设计思想,它可以同时指导中台业务建模和微服务设计(中台本质是业务模型,微服务是业务模型的系统落地),领域驱动设计强调领域模型和微服务设计的一体...
  • 应用架构、业务架构、技术架构和业务流程图详解

    万次阅读 多人点赞 2018-10-09 18:48:32
    应用架构 应用架构(Application Architecture)是描述了IT系统功能和技术实现的内容。应用架构分为以下两个不同的层次: 企业级的应用架构:企业层面的应用架构起到了统一规划、承上启下的作用,向上承接了企业...
  • 微信技术总监分享架构设计高清完整PDF版

    万次下载 热门讨论 2012-05-15 09:17:26
    在技术架构上,微信是如何做到的?日前,在腾讯大讲堂在中山大学校园宣讲活动上,腾讯广研助理总经理、微信技术总监周颢在两小时的演讲中揭开了微信背后的秘密。
  • 从MVC框架看MVC架构的设计

    万次阅读 多人点赞 2011-08-16 09:57:37
    从MVC框架看MVC架构的设计尽管MVC早已不是什么新鲜话题了,但是从近些年一些优秀MVC框架的设计上,我们还是会发现MVC在架构设计上的一些新亮点。本文将对传统MVC架构中的一些弊病进行解读,了解一些优秀MVC框架是...
  • B/S架构及其运行原理

    万次阅读 多人点赞 2018-03-23 22:31:19
    目录 一. B/S的概念 二. B/S工作原理 三....四....五....一.... B/S(Brower/Server,浏览器/服务器)模式又称B/S结构,是Web兴起后的一种网络结构模式。... 这种模式统一了客户端,将系统功能实现的核心部分...
1 2 3 4 5 ... 20
收藏数 1,878,332
精华内容 751,332
关键字:

架构