精华内容
下载资源
问答
  • 架构设计

    千次阅读 2014-06-05 16:52:21
    1.每个人都是架构师 2.对架构设计的理解 3.架构设计解决的问题 4.架构设计五视图 5.如何后期使用架构设计

    1.每个人都可以做成为架构设计师

    不懂软件的和刚入行的人们一听到架构设计,都认为是非常的高大上课题,是一个遥不可及的领域,一般人是不能做的。听起来云里雾里的,第一印象除了来自微软,阿里这些NB的公司里面的人其余的都不能做出架构似的,这是一种先入为主的思想,因为大家都在强调架构师的重要性,他的薪资有多么的高,在整个社会对他的认定导致很多人对架构设计望而生畏。放正自己的心态其实架构设计并没有多么的复杂。我们是从编码入行的,在编码实现功能的过程中我们或多或少的设计了属于自己的软件架构了。

    为什么说软件架构师需要多少年的工作经验,因为软件架构就是系统的草图,不仅是代


    码编写而且包括部署,运行、开发等这些方面进行设计,目的是为了保证软件开发、运行、扩展、性能、安全、伸缩等等质量的一个保证。只要在编码过程中不仅仅要提升编码的质量而且要留心其他方面的知识积累与学习,用不了多久你也能成为一位优秀的架构设计师。

    2.什么是架构设计

    我们要成为架构设计师我们需要了解什么是架构设计。简单一点,架构设计就是一个系统的草图,描述了构成系统的抽象组件,以及各个组件之间的是如何进行通讯的,这些组件在实现过程中可以被细化为实际的组件比如类或者对象。在面向对象领域中,组件之间的联通通常面向于接口实现的。

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

    架构和结构会难以区分,明确一点架构不是结构,IEEE把架构定义为“系统在其环境中的最高层概念”架构还包括系统完整性、经济约束条件、审美需求和样式等。在Rational Unified Process 中对软件架构的解释:软件架构指系统重要构建的组织或结构,这些重要的构建通过接口与其他构建进行交互。

    总体来说软件架构对软件从整体到部分的描述,从开发到运行再到后期扩展的描述,从性能和安全可靠性进行描述。

    3.架构设计为了解决什么问题

    开发之初逻辑设计阶段要确定系统如何开发,整个系统融合为一个系统开发还是从业务角度将系统拆分为几个独立的子系统。

    在即将进入开发的时候关注了数据是如何持久化的,以及数据库选型、以及非数据库文件的存储格式,等这些存储方案的确定。

    在开发过程中我们要关注如何保证开发质量,如何分层,代码可扩展性,使用的设计模式,依赖了那些框架,开发语言这些方向的确定。

    开发完成之后进入运行阶段,如何在架构设计的时候保证运行期间的质量属性、性能、可伸展性等,主要是系统运行进程的划分,以及进程之间通过线程来通信。

    同时如果系统并非是单机运行,还需考虑系统的物理部署,系统部署在那个服务器上,这些服务器配置性能怎样能否胜任系统的运行,操作系统选型,以及系统部署的网络拓扑图,还有就是保证数据安全的数据备份怎样设计的。

    以上五个问题是从五个角度来确定架构以及架构设计需要解决的问题。

    4.架构设计的五视图法

    我们刚才从五个不同的角度知道架构设计需要解决的问题,那么使用五视图法就更加系统的分析设计我们架构了


    从这幅图里面我们可以看出架构设计五视图中各个角度需要解决的问题了,并且可以看出他们之间的联系了。

    5.后期如何使用使用架构设计

    无论多么好的架构如果只是为了设计完成任务都是毫无意义的,我们设计出来的架构无论是好或不好我们首先需要按照架构设计来完成系统的开发,作为项目的Leader就需要严格按照架构设计出来的标准进行检查,无论我们的开发模式敏不敏捷,到一定时间都有一个里程碑的阶段,到了这个阶段Leader牵头严格按照架构设计文档中相应的章节对开发出来的系统进行检查,及早发现问题及早解决,不要把问题向后面推。

    展开全文
  • 架构设计(2)-架构设计原则

    万次阅读 2017-10-17 14:19:01
    如何设计出一个好的架构,不像数据公式或者定律,很难一概而就...一些好的架构设计原则可以确保设计决策在一定程度上能够满足需求。 一、形成架构原则的过程 形成架构原则的过程: 架构原则要SMART ...

     

    架构设计学习思维导图: 架构设计系列主要的ADM(架构开发方法)主要基于TOGAF9或者TOGAF9.1来论述。这是个人学习实践和总结笔记,专注并不断积累和更新,努力精进自己。个人拙见,仅供参考。
    1、 架构概述:了解架构基础知识:架构定义、分类、级别、应用架构演进、架构是否合理、架构误区等。
         《谈谈架构》
    2、 原则模式:了解架构模式和设计原则。
         《架构设计原则》
          《架构模式》
    3、 瀑布模式:根据瀑布开发模式,从前期的架构愿景->到架构需求分析->架构设计
          《架构愿景分析》
          《架构需求分析》
          《如何设计一个架构》
    4、 架构三高:架构战术设计主要关注点:高可用、高性能、高效服务治理或者高并发
         《高可用架构设计》
         《高性能设计》
         《分布式服务治理》
    5、 具体知识点:架构实施知识点,框架、组件、限流、容错等知识。
         《分布式链路跟踪》
         《分布式链路跟踪:Zipkin实践》
         《分布式链路跟踪:skywalking实践》
         《我们自研log2跟踪组件》

     

    前言


    原则定义:行事所作为依据的准则、规范、标准,是指经过长期经验总结所得出的合理化的现象。

    生活中的原则

    我们在生活中,说这人原则性很强,即他做人做事严格按照自己制定的准则规范。原则性很强的人在生活和工作中遇到需要抉择的情境时,根据自己原则毫不犹豫地作出选择。而没有原则的人往往是犹豫不决,优柔寡断。

    架构的原则

         我们在《架构设计(1)-谈谈架构》的架构定义也提到架构的第一条内容:
         系统性思考的合理决策:比如技术选型、解决方案、成本评估、性价比评估等等。那如何评估决策的合理性呢?如何评估架构设计的合理性?比如老板说N+1容灾部署成本太高,架构设计不合理. 那怎么怼老板呢?

    架构原则源于业务目标

      

    架构设计不像数据公式或者定律,很难一概而就。很多时候是设计者(架构师)的各种设想,各种权衡折中而符合系统需求的智慧输出。一些好的架构设计原则可以确保设计决策在一定程度上能够满足需求。

              

     

    一、形成架构原则的过程


    架构原则不是某个架构师拍脑袋决定,可能是架构师提出最初文档,然后经过了团队成员内部反复讨论和共同认可后才得以确定和精炼的。形成架构原则的过程:

      架构原则要SMART 

    具体SMART原则有不同的解释:
    SMART原则1(S=Specific具体、M=Measurable度量、A=Attainable实现、R=Relevant相关、T=Time-bound时限)
    SMART原则2(S=Specific具体、M=Measurable度量、A=Attainable实现、R=Realistic实际、T=Testable 可验证)

     

    二、架构原则分级


    分类和分级说明原则,目的是明确原则的适用范围。

    1、从架构分类说明

    下面部分图来自《京东架构介绍》ppt。

    1)、系统级架构原则:


    2)、业务架构原则

    3)、应用架构原则

    4)、数据架构原则

    5)、代码架构原则

          应用程序开发中,一般要求尽量两做到可维护性和可复用性。我个人理解是常用的7个面向对象设计原则。这些原则并不是孤立存在的,它们相互依赖,相互补充。具体参考《设计模式原则详解》和《设计模式概论》提到相关原则。

     

    6)、技术架构原则

     

     

    2、从服务分级来说明:

    明确每个服务级别的原则要求。《架构设计(8)—高可用架构设计》服务分级治理也提到相关原则

    类别 服务 原则 描述
    一级核心服务 核心产品或者服务 冗余N+1部署、可监控、可回滚等原则 系统引擎部分:一旦出现故障,整个系统瘫痪
    二级重要服务 重要的产品功能 可监控、可回滚等原则 类比汽车轮子:该服务出现问题,该重要功能不可用。
    三级一般服务 一般功能 可以单点部署等原则 类比汽车倒车影像:该部分出现问题,稍微影响用户体验
    四级工具服务 工具类是服务 混合部署、不监控等原则 非业务功能:比如爬虫、管理后台、运维工具

    在此就可以回答老板“N+1容灾部署成本太高,架构设计不合理”的问题。核心服务必须N+1部署,保证系统的高可用。

     

    三、15条普适架构原则


    我们掌握前人总结的经验,让我们站在巨人的肩膀上高山远瞩。《架构真经》这本书简单阐述了架构设计的一些常用的原则。罗列一些常用的原则,下面是15个具有普适价值架构原则 :

    1、N+1设计 :开发的系统在发生故障时,至少有一个冗余的实例
    2、回滚设计 :确保系统可以向后兼容。
    3、禁用设计:可以关闭任何发布功能
    4、监控设计 :在设计阶段就要考虑监控,而不是在部署完成后。
    5、多活数据中心设计
    6、采用成熟的技术
    7、故障隔离 :
    8、水平扩展
    9、非核心则购买
    10、使用商品化硬件
    11、快速迭代
    12、异步设计
    13、无状态设计
    14、前瞻性设计
    15、自动化

    1、N+1设计 :开发的系统在发生故障时,至少有一个冗余的实例

       广泛地应用在从数据中心设计到应用服务的部署:

    • 在发生故障时,系统至少要有一个冗余的实例。
    • 必须确保一个为自己,一个为客户、 一个为失败


    2、回滚设计 :确保系统可以向后兼容。

    • 如果很久才能修复服务,那么就要在一定的时间范围内完成回滚。
    • 灾难性的事故,例如损坏客户数据,往往在部署后好几天才出现。
    • 系统最好按照预先的设计,通过发布或回滚解决问题。

        通过版本化方式实现回滚设计,一旦发生灾难级别的故障可以通过回滚到最近版本来恢复服务。

    3、禁用设计(功能开关、降级开关):可以关闭任何发布功能

         当设计系统,特别是与其他系统或服务通讯的高风险系统时,要确保这些系统能够通过开关来禁用。这将为修复服务提供额外的时间,同时确保系统不因为错误引起诡异需求而宕机。

     

         降级开关通过配置中心集中化管理,例如(apollo配置中心)通过推送机制把开关推送到各个应用服务。

     

    4、监控设计 :在设计阶段就要考虑监控,而不是在部署完成后。

       通过监控发现系统的可用性问题。

    •  通过监控使系统自我诊断、自我修复成为可能。
    •  通过监控确定系统可预留空间的使用情况。
    •  通过监控掌握系统之间的交互关系,发现瓶颈 

        如果监控做的好,不仅能发现服务的死活,检查日志文件,还能收集系统相关的数据,评估终端用户的响应时间。如果系统和应用在设计和构建时就考虑好监控,那么即使不能自我修复,也至少可以自我诊断。

    5、多活数据中心设计

    • 数据是否全部集中在一个数据中心?
    • 读写是否分离?
    • 是否所有的客户信息都共享同一个数据结构?
    • 服务调用是否允许延时的存在


    6、采用成熟的技术

    •  工程师倾向于学习和实施性感时髦的新技术。因为新技术可以降低成本、减少产品上市时间、提高性能。不幸的是,新技术也往往有较高的故障率。如果把新技术应用在架构的关键部分,可能会对可用性产生显著的影响。
    •  最好争取在多数人采用该技术的时候进入,先把新技术用在对可用性要求不高的功能上,一旦证明它可以可靠地处理日常的交易,再将此技术移植到关键任务领域中去。

    7、故障隔离 :

         1、避免单一业务占用全部资源。避免业务之间的相互影响  2. 机房隔离避免单点故障。
         不共享原则:理想情况是负载均衡、网络前端、应用服务器、数据库,绝不共享任何服务、硬件和软件。
         不跨区原则: 不同隔离区之间无通讯,所有服务调用必须发生在同一个故障隔离区。

    8、水平扩展

        什么是水平可扩展?平台的水平扩展是指随着业务的发展,当需要扩大平台的服务能力时,不必重构软件系统,通过增加新的设备来满足业务增长的需要。 


     X轴扩展:服务器拆分。平台的服务能力可以在不改变服务的情况下,通过添加硬件设备来完成扩容。

     Y轴扩展:数据库拆分。平台的服务能力通过不断地分解和部署服务来完成扩容。

     Z轴扩展:功能拆分。平台的服务能力可以按照客户不断分解和部署来机器 完成容量的扩展。(比如按用户uid来分表分库等)

     

    9、非核心则购买 

    工程师往往有自己研发所有系统的冲动,如果使用云服务器,建议直接使用云服务相关产品,比如日志系统,可以直接使用日志服务。

    •   系统研发要投入资源,系统维护更要长期投入。
    •   影响核心产品到市场的速度。
    •   如果可以形成差异化的竞争优势,那么自己做,否则外购。

    10、使用商品化硬件 

    •      在大多数情况下,便宜的是最好的。
    •      标准、低成本、可互换、易于商品化是商品化硬件的特征。

          如果架构设计得好,就可以通过购买最便宜的服务器轻松地实现水平扩展,前提是所有商品化硬件的总成本要低过高端硬件的总成本。

    11、快速迭代

    • 小构建:小构建的成本较低,可以确保投资可以产生价值。
    • 小发布:发布的失败率与变更数量相关,小发布失败率较低。
    • 快试错:可依市场反馈,快速迭代,加快TTM,优化用户体验。

    快速迭代需要完善的运维工具,比如从cmdb,持续集成工具,监控等等。

    12、异步设计

    同步系统中个别子系统出现故障会对整个系统带来影响。

    • 同步系统中性能最慢的子系统成为整个系统性能的瓶颈。
    •  同步系统中扩展性最差的子系统是整个系统扩展的瓶颈。 
       

    13、无状态设计

    无状态定义:是应用服务运行的实例不会在本地存储需要持久化的数据,并且多个实例对于同一个请求响应的结果是完全一致的。比如单实例的mysql,zookeeper集群是有状态,而类似单纯tomcat服务是无状态的。

    无状态的系统更利于扩展,更利于做负载均衡。状态是系统的吞吐量、易用性、可用性、性能和可扩展性的大敌,要尽最大可能避免。

    14、前瞻性设计

    • Now :目前正使用系统的架构、设计、能力、性能和扩展性。
    • Now+1: 下一代预研系统的架构、设计、能力、性能和扩展性。
    • Now+2: 下一代规划系统的架构、设计、能力、性能和扩展性


    15、自动化

    设计和构建自动化的过程。如果机器可以做,就不要依赖于人. 人常犯错误,更令人沮丧的是,他们往往会以不同的方式多次犯同样的错误。

    四、应用服务拆分原则


    应用拆分首先明确拆分目的和需求,然后制定拆分原则。

    4.1、拆分的目的

    1. 人员的角度:  多人维护一个工程,从开发开发、测试、部署、上线,效率是极低的。定位问题和修复问题非常困难。
    2. 业务的角度:代码已经严重影响到业务的效率,每个业务有各自的需求,需要给自己应用部署,各自开发需求。
    3. 从架构的角度:应用已经无法满足非功能性需求:无法满足并发需求、安全性、扩展维护很麻烦。需要梳理和抽取核心应用、公共应用,作为独立的服务下沉到核心和公共能力层,逐渐形成稳定的服务中心

         总之,系统拆分是单体程序向分布式系统演变的关键一步,也是很重要的一步,拆分的好坏直接关系到未来系统的扩展性、可维护性和可伸缩性等,拆分工作不难理解,但是如何正确拆分、有什么样的方法和原则能帮助我们拆分得到一个我们理想中的系统:高可用、可扩展、可维护、可伸缩的分布式系统。

    4.2、拆分需求

    1. 组织结构变化:从最初的一个团队逐渐成长并拆分为几个团队,团队按照业务线不同进行划分,为了减少各个业务系统和代码间的关联和耦合,几个团队不再可能共同向一个代码库中提交代码,必须对原有系统进行拆分,以减少团队间的干扰。
    2. 安全需求:这里所指的安全不是系统级别的安全,而是指代码或成果的安全,尤其是对于很多具有核心算法的系统,为了代码不被泄露,需要对相关系统进行模块化拆分,隔离核心功能,保护知识产权。
    3. 替换性:有些产品为了提供差异化的服务,需要产品具有可定制功能,根据用户的选择自由组合为一个完整的系统,比如一些模块,免费用户使用的功能与收费用户使用的功能肯定是不一样的,这就需要这些模块具有替换性,判断是免费用户还是收费用户使用不同的模块组装,这也需要对系统进行模块化拆分。
    4. 交付速度:单体程序最大的问题在于系统错综复杂,牵一发而动全身,也许一个小的改动就造成很多功能没办法正常工作,极大的降低了软件的交付速度,因为每次改动都需要大量的回归测试确保每个模块都能正确工作,因为我们不清楚改动会影响到什么,所以需要做大量重复工作,增加了测试成本。这时候就需要对系统进行拆分,理清各个功能间的关系并解耦。
    5. 技术需求:
    6. 1)、 扩展困难:单体程序由于技术栈固定,尤其的是比较庞大的系统,不能很方便的进行技术升级,或者说对引入新技术或框架等处于封闭状态;每种语言都有自己的特点,单体程序没有办法享受到其它语言带来的便利;对应到团队中,团队技术相对比较单一。
    7.  2)、 减少重复造轮子:相比于基于业务的垂直拆分,基于技术的横向拆分也很重要,使用数据访问层可以很好的隐藏对数据库的直接访问、减少数据库连接数、增加数据使用效率等;横向拆分可以极大的提高各个层级模块的重用性,减少重复造轮子。
    8. 6)、业务需求:由于业务上的某些特殊要求,比如对某个功能或模块的高可用性、高性能、可伸缩性等的要求,虽然也可以将单体整体部署到分布式环境中实现高可用、高性能等,但是从系统维护的角度来考虑,每次改动都要重新部署所有节点,显然会增加很多潜在的风险和不确定定性因素,所以有时候不得不选择将那些有特殊要求的功能从系统中抽取出来,独立部署和扩展。

     

    4.3.拆分原则

    4.3.1、业务原则

    1. 单一职责:1)、满足单一职责原则对于一个微服务而言,有限定的业务边界,可以帮助我们满足服务开发和交付的敏捷性;即每一个组件或者是模块应该只有一个职责或者是功能,功能要内聚。2)、高内聚、低耦合:拆分主要的参考因素就是最小化交互,高内聚、低耦合。错误的拆分边界,可能会导致功能之间的高耦合性和复杂性。3)、最小知识原则:一个组件或者是模块不应该知道其他组件或者模块的内部实现细节。
    2. 服务粒度适中:以业务模型拆分、有适当的边界。 1)、粗粒度优行原则:由服务提供方提供粗粒度的业务服务,封装数据及数据处理逻辑,屏蔽数据及业务规则,降低耦合度,提供更多业务价值;2)、适当边界:关注微服务的功能范围,一个服务的大小应该等于满足某个特定业务能力所需要的大小;
    3. 业务分层原则: 从整体规划上把业务分层,形成单向依赖,避免微服务之间的网状依赖关系;
    4. 可重用性拆分原则:将通用部分和专用部分分解为不同的应用。1) 若粗粒度服务不能满足重用需求,则拆分粗粒度服务,以增加重用;2)非唯一依赖:至少被2个以上其它微服务依赖的功能模块,才有必要独立成一个微服务。
    5. 稳定性原则:将稳定部分和易变部分分离。将动态部分和静态部分分解为不同的元素;将机制和策略分离为不同的元素;将应用和服务分离。

     

    4.3.2、技术原则

    1. 低耦合:可独立部署
    2. 轻量级的通信机制
    3. 性能要求拆分原则:若粗粒度服务性能达不到性能需求,则适当拆分服务,以满足性能需求;
    4. 安全性拆分原则:若粗粒度服务所包含的所有处理不在同一个安全级别上,为满足安全性需求拆分服务形成细粒度服务;

     

    4.3.3 其他治理原则

    1. 演进式拆分
    2. 考虑团队人员结构
    3. 避免环形依赖和双向依赖

    对于微服务组件拆分粒度应该是尽可能的拆小,但也不应该过分追求细粒度,要考虑适中不能过大或过小。按照单一职责原则和康威定律,在业务域、团队还有技术上平衡粒度。拆分后的代码应该是易控制,易维护的,业务职责也是明确单一的。

     

    五、技术选型: 指导原则


    架构设计并没有像编程语言那样的语法约束,更多的时候是面多多种可能时的“选择”,例如:

    • 选先进的技术还是团队熟悉的技术?先进的出问题怎么办?熟悉的后续技术演化困难怎么办?
    • 用Angular还是React,一个很强大一个更灵活
    • MySQL还是MongoDB?
    • 淘宝的电商架构咳哟简单的照搬么?
    • 等等

    但存在共性原则:合适原则、简单原则、演化原则

    1、合适原则:合适优于业界领先

    优秀人才的技术情节导致各种以先进技术主导的创业失败,原因有:

    1. 将军难打无兵之仗(人数)
    2. 罗马不是一天建成的(积累)
    3. 冰山下面才是关键(业务)

    所以真正的优秀架构都是在企业当前人力、条件、业务等各种约束下设计出来的。BAT的架构师到小公司没有了大公司的资源、平台、积累和业务,只照搬大公司的做法和技术即会失败!

    我们架构设计核心目标是解决问题,提高效率。所以合适于业务场景需求的架构设计才是首要选择,而不是以追求实施性感时髦的新技术。

    2、简单原则:简单优于复杂。

    软件架构设计目的就是为了解决系统的复杂度。系统组成结构和相关之间关系越复杂,出问题的可能性就越大。扩展的难度也就越大,很有可能牵一发而动全身。

    软件领域复杂度体现两个方面:

    1)、结构的复杂性

    • 组成复杂系统的组件数量更多
    • 同时这些组件之间的关系也更加复杂
    • 组件增多整体出现鼓掌的概率增加,可用性下降
    • 某个组件改动会影响关联的所有组件
    • 定位复杂系统的问题比简单系统更加困难

    2)、逻辑的复杂性

    • 单组件承担功能过多,导致逻辑复杂度升高
    • 后续的功能修改会影响很大
    • 使用了复杂的算法难以实现修改和问题解决

    简单变复杂的事情可能人人都会,但化繁为简会很难。正所谓大道至简,如果简单和复杂的都能满足需求,最好选择简单的方案!

    3、演化原则:演化优于一步到位. 架构设计没有完美银弹. 勿过度设计.  

    业务需求是不断变化的,所以架构设计需要不断随着业务变化而变化的,这样才能去适应业务需求。软件架构同建筑架构相似,但建筑不可变,软件可变, 例如:Windows的演化、Android的发展。

    软件架构类似于大自然“设计”的一个生物,通过演化适应环境,逐步变得强大。

    1. 首先满足当前需要,解决当前最核心问题. 
    2. 预测并并发未来可能存在的问题,  不断迭代保留,不断完善, 
    3. 业务变化时,架构扩展、重构、甚至重写。

    不要贪大求全,分析清楚自身业务特点,快速落地,不断完善演化。当然如果一开始系统就有很好的基础设计, 未来可能更容易到达满意的目标.  

     

    所有问题的前提要搞清楚我们今天面临的业务量有多大,增长走势是什么样,而且解决高并发的过程,一定是一个循序渐进逐步的过程。例如在初创公司的野蛮生长阶段,业务场景和需求边界很难把握,有时候根本不需要架构师,产品需要快速迭代和变现,需求频繁更新,这个时候需要的是快速实现。这时候考虑如何做好架构设计, 如何微服务化, 可能会影响业务的发展. 

    网上的一张图很经典,总结的非常好:

     

    整个系统进化分为三个阶段:

    x轴,水平扩展阶段,通过负载均衡服务器不断的横向扩充应用服务器,水平扩展最重要的问题是需要注意不用服务器之间的如何保持session和会话同步,不能让用户在不通服务器之间切换时有感知应用扩展后自然遇到的问题就是DB的瓶颈:连接数,iops等。

    z轴,就是对数据库的拆分,难度上了一个台阶,Sharding的基本思想就要把一个数据库如何进行切分,可以分为水平切分和垂直切分,水平切分相对简单,一主多从,多主都可以,根据业务的需要,多主切分设计时需要注意主键的关系,解决多写在进行数据同步时候的冲突问题,垂直拆分更加复杂,一般都会涉及到架构逻辑的改造,需要引入中间件,来进行数据源的管理,垂直拆分时把关系紧密(比如同一模块)的表切分出来放在一个库上,或者通过hash进行拆分,从而将原有数据库切分成类似矩阵一样可以无限扩充的队列。

    y轴扩展,最后就是功能分解了,也就是我们讲的微服务切分。微服务拆分将巨型应用按照功能模块分解为一组组不同的服务,淘宝的系统当年也经历了这样的过程,通过五彩石项目从单一的war包拆分成了今天的大家看到买家,卖家中心,交易等系统。

     

    六、优秀程序设计的18大原则


    良好的编程原则与良好的设计工程原则密切相关。本文总结的这些设计原则,帮助开发者更有效率的编写代码,并帮助成为一名优秀的程序员。作者Diggins是加拿大一位有25年编程经验的资深技术人员,曾效力于Microsoft和Autodesk,并创办过两家赢利的互联网公司。

    1.避免重复原则(DRY - Don’t repeat yourself)

    编程的最基本原则是避免重复。在程序代码中总会有很多结构体,如循环、函数、类等等。一旦你重复某个语句或概念,就会很容易形成一个抽象体。

    2.抽象原则(Abstraction Principle )

    与DRY原则相关。要记住,程序代码中每一个重要的功能,只能出现在源代码的一个位置。

    3.简单原则(Keep It Simple and Stupid )

    简单是软件设计的目标,简单的代码占用时间少,漏洞少,并且易于修改。

    4.避免创建你不要的代码 Avoid Creating a YAGNI (You aren’t going to need it)

    除非你需要它,否则别创建新功能。

    5.尽可能做可运行的最简单的事(Do the simplest thing that could possibly work)

    尽可能做可运行的最简单的事。在编程中,一定要保持简单原则。作为一名程序员不断的反思“如何在工作中做到简化呢?”这将有助于在设计中保持简单的路径。

    6.别让我思考(Don’t make me think )

    这是Steve Krug一本书的标题,同时也和编程有关。所编写的代码一定要易于读易于理解,这样别人才会欣赏,也能够给你提出合理化的建议。相反,若是繁杂难解的程序,其他人总是会避而远之的。

    7.开闭原则(Open/Closed Principle)

    你所编写的软件实体(类、模块、函数等)最好是开源的,这样别人可以拓展开发。不过,对于你的代码,得限定别人不得修改。换句话说,别人可以基于你的代码进行拓展编写,但却不能修改你的代码。

    8.代码维护(Write Code for the Maintainer)

    一个优秀的代码,应当使本人或是他人在将来都能够对它继续编写或维护。代码维护时,或许本人会比较容易,但对他人却比较麻烦。因此你写的代码要尽可能保证他人能够容易维护。用书中原话说“如果一个维护者不再继续维护你的代码,很可能他就有想杀了你的冲动。”

    9.最小惊讶原则(Principle of least astonishment)

    最小惊讶原则通常是在用户界面方面引用,但同样适用于编写的代码。代码应该尽可能减少让读者惊喜。也就是说,你编写的代码只需按照项目的要求来编写。其他华丽的功能就不必了,以免弄巧成拙。

    10.单一责任原则(Single Responsibility Principle)

    某个代码的功能,应该保证只有单一的明确的执行任务。

    11.低耦合原则(Minimize Coupling)

    代码的任何一个部分应该减少对其他区域代码的依赖关系。尽量不要使用共享参数。低耦合往往是完美结构系统和优秀设计的标志。

    12.最大限度凝聚原则(Maximize Cohesion)

    相似的功能代码应尽量放在一个部分。

    13.隐藏实现细节(Hide Implementation Details)

    隐藏实现细节原则,当其他功能部分发生变化时,能够尽可能降低对其他组件的影响。

    14.迪米特法则又叫作最少知识原则(Law of Demeter)

    该代码只和与其有直接关系的部分连接。(比如:该部分继承的类,包含的对象,参数传递的对象等)。

    15.避免过早优化(Avoid Premature Optimization)

    除非你的代码运行的比你想像中的要慢,否则别去优化。假如你真的想优化,就必须先想好如何用数据证明,它的速度变快了。

    “过早的优化是一切罪恶的根源”——Donald Knuth

    16.代码重用原则(Code Reuse is Good)

    重用代码能提高代码的可读性,缩短开发时间。

    17.关注点分离(Separation of Concerns)

    不同领域的功能,应该由不同的代码和最小重迭的模块组成。

    18.拥抱改变(Embrace Change)

    这是Kent Beck一本书的标题,同时也被认为是极限编程和敏捷方法的宗旨。

    许多其他原则都是基于这个概念的,即你应该积极面对变化。事实上,一些较老的编程原则如最小化耦合原则都是为了使代码能够容易变化。无论你是否是个极限编程者,基于这个原则去编写代码会让你的工作变得更有意义。
     

     

    七、架构设计非侵入性原则


           架构的侵入性:所谓侵入性就是指的这个架构设计出来的部件对系统的影响范围,比如框架的侵入性就很高,因为在一个工程中引入一个框架,你的整个设计都必须围绕这个框架来进行,一旦使用了,框架的可替代性几乎为0,这样子就是搞侵入性。组件的侵入性就比较低,比如ibaties,他可以在任何java框架下使用,甚至可以和其他ORM组件共存,你仅仅需要引入,配置,然后就可以使用了,你也可以用其他的ORM替换他,所以......这个体验应该是很愉快的。
          所以话说回来说到如果我们在设计一个通用架构的时候就应该注意到这个一个非常重要的地方,除非我们只是自己拿来用用,否则我们不应该假设我们的设计的用户已经具备怎么怎么样的环境或者是需要做什么特殊的设计才能够使用。
            这里打个比方,假如说我们在设计一个通用权限管理什么什么的时候我们就要想好,这是一个组件,还是框架,还是一个现成系统(复用通过改改代码实现,其实个人觉得这种设计很低级,虽然有的这样子的东西功能确实丰富)。确定了目标之后我们才好开始下一步,比如确定是一个框架的话可能发挥要自由一些,因为不需要高度的内聚,不过可能因为框架要设计的方方面面太多了,所以老是觉得个人的力量不足以搞这种东西出来。如果是组件的话就需要高度的内聚来实现非侵入式,比如引入DLL的时候还需要让所有页面继承自某个基类页就不算是一个good idear。
           虽然话说得好听,不过我在自己做设计的时候还是常常因为功力不够造成一些侵入的现象,但是高内聚低耦合都是我们不断追求的目标,所以所有做设计的同学们一起努力吧

    参考总结《大型网站技术架构》《架构真经》

    展开全文
  • 架构设计(1)-谈谈架构

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

    架构设计学习思维导图: 架构设计系列主要的ADM(架构开发方法)主要基于TOGAF9或者TOGAF9.1来论述。这是个人学习实践和总结笔记,专注并不断积累和更新,努力精进自己。个人拙见,仅供参考。
    1、 架构概述:了解架构基础知识:架构定义、分类、级别、应用架构演进、架构是否合理、架构误区等。
         《谈谈架构》
    2、 原则模式:了解架构模式和设计原则。
         《架构设计原则》
          《架构模式》
    3、 瀑布模式:根据瀑布开发模式,从前期的架构愿景->到架构需求分析->架构设计
          《架构愿景分析》
          《架构需求分析》
          《如何设计一个架构》
    4、 架构三高:架构战术设计主要关注点:高可用、高性能、高效服务治理或者高并发
         《高可用架构设计》
         《高性能设计》
         《分布式服务治理》
    5、 具体知识点:架构实施知识点,框架、组件、限流、容错等知识。
         《分布式链路跟踪》
         《分布式链路跟踪:Zipkin实践》
         《分布式链路跟踪:skywalking实践》
         《我们自研log2跟踪组件》

    一、架构是什么


          在软件行业,对于什么是架构,都有很多的争论,每个人都有自己的理解。 此君说的架构和彼君理解的架构未必是一回事。因此我们在讨论架构之前,我们先讨论架构的概念定义, 因为概念是人认识这个世界的基础和用来沟通的手段,如果对架构概念理解不一样,那沟通起来自然不顺畅。

         Linux有架构,MySQL有架构,JVM也有架构,使用Java开发、MySQL存储、跑在Linux上的业务系统也有架构,应该关注哪一个?想要清楚以上问题需要梳理几个有关系又相似的概念:系统与子系统、模块与组建、框架与架构:  

    一、系统与子系统

    系统:泛指由一群有关联的个体组成,根据某种规则运作,能完成个别元件不能独立完成的工作能力的群体。

    子系统:也是由一群关联的个体组成的系统,多半是在更大的系统中的一部分。

    二、模块与组件

    都是系统的组成部分,从不同角度拆分系统而已。模块是逻辑单元,组件是物理单元。

    模块就是从逻辑上将系统分解, 即分而治之, 将复杂问题简单化。模块的粒度可大可小, 可以是系统,几个子系统、某个服务,函数, 类,方法、 功能块等等。

    组件可以包括应用服务、数据库、网络、物理机、还可以包括MQ、容器、Nginx等技术组件。

    三、框架与架构

    框架是组件实现的规范,例如:MVC、MVP、MVVM等,是提供基础功能的产品,例如开源框架:Ruby on Rails、Spring、Laravel、Django等,这是可以拿来直接使用或者在此基础上二次开发。

    框架是规范,架构是结构。

    在TOGAF9是这么定义:一个系统基本的构件(子系统, 模块, 组件),体现在它的各个构件、构件间的相互关系、构件与环境间的关系,以及对系统设计和演进进行治理的原则中。两种含义:
    (1)、一个系统的形式化描述,或指导系统实现的构件级的详细计划。
    (2)、一组构件的结构、构件间的相互关系、以及对这些构件的设计和随时间演进的过程进行治理的一些原则和指导策略

    我在这重新定义架构:软件架构指软件系统顶层结构设计。

    架构是经过系统性地思考, 权衡利弊之后在现有资源约束下的最合理决策, 最终明确的系统骨架: 包括子系统, 模块, 组件. 以及他们之间协作关系, 约束规范, 指导原则.  并由它来指导团队中的每个人思想层面上的一致。

    涉及四方面:

    1、系统性思考的合理决策:比如技术选型、解决方案、成本评估、性价比评估等等。

    2、明确的系统骨架:明确系统有哪些部分组成。

    3、系统协作关系:各个组成部分如何协作来实现业务请求。

    4、约束规范和指导原则:保证系统有序,高效、稳定运行,包括规范、原则、流程等内容。

     

        

    二、架构设计目的


          如果没有架构设计,说明你的系统不够复杂。随着业务的增长,系统由单体应用渐进演化为分布式和微服务化。系统整体的复杂性越来越高,技术团队可能从一个团队变成多个专业化团队。假如没有架构设计,系统定会是一个无序失控的状态,带来的问题:

          1、应用服务的边界不是很清晰:到底该怎么拆分没有一个明确的原则,研发人员为了所谓微服务化而拆分,而不是从当前业务考虑。我们系统出现过类似的情况:一个简单项目拆分成8个子服务,问他为什么这么拆分,说微服务化是为了应对以后扩展方便。结果这个项目从2017年到现在都没有再修改过,接手人宁愿新开发一个项目也不愿重构。

          2、应用服务层次不清晰:导致服务依赖出现网状依赖结构。

          3、系统应用服务跟踪问题:由于微服务化后,服务出现问题后,你很难快速的定位问题。这是我们踩过不少坑,我们使用dubbo服务化,系统一旦出现问题,一推人手忙脚乱。

          4、系统服务监控问题:由于研发人员基本没有服务监控意识,都是出现问题后再想办法如何添加服务监控接口。

           5、技术体系失控问题:不同的开发团队使用不同的技术栈或者组件,造成公司内部的技术架构失控。甚至研发人员为追求时髦新潮技术,拿应用项目来试验新技术。

           。。。。。。  能列举出来还有多各种各样问题。

     

          架构设计的目的是为了解决系统复杂性带来的问题,其本质就是对系统进行有序化地重构以致符合当前业务的发展,并可以快速扩展。从上面架构的定义,也知道架构设计的作用涉及四方面:1、系统性思考的合理决策。2、明确的系统骨架。3、系统协作关系4、约束规范和指导原则。

    架构师通过理解业务,全局把控,选择合适技术,解决关键问题、指导研发落地实施,促进业务发展,提高效率。

     那什么样的系统要考虑做架构设计?  技术不会平白无故的出和自驱动发展起来,而架构的发展和需求是基于业务的驱动。

    1.  需求相对复杂.
    2.  非功能性需求在整个系统占据重要位置.
    3.  系统生命周期长,有扩展性需求.
    4.  系统基于组件或者集成的需要.
    5.  业务流程再造的需要.

     

    三、架构分类


    RUP4+1架构视图

    1995年,Philippe Kruchten在《IEEE Software》上发表了题为《The 4+1 View Model of Architecture》的论文,引起了业界的极大关注,并最终被RUP采纳。即RUP4+1架构方法。该方法主要采用用例驱动,在软件生命周期的各个阶段对软件进行建模,从不同视角对系统进行解读,从而形成统一软件过程架构描述.

    该方法的不同架构视图承载不同的架构设计决策,支持不同的目标和用途:

    逻辑视图:用于描述系统软件功能拆解后的组件关系,组件约束和边界,反映系统整体组成与系统如何构建的过程。关注功能和逻辑层。

    开发视图:描述系统的模块划分和组成,以及细化到内部包的组成设计,服务于开发人员,反映系统开发实施过程。

    物理视图:描述软件如何映射到硬件,反映系统在分布方面的设计,系统的组件是如何部署到一组可计算机器节点上,用于指导软件系统的部署实施过程。

    处理流程视图:用于描述系统软件组件之间的通信时序,数据的输入输出,反映系统的功能流程与数据流程,通常由时序图和流程图表示。关注进程、线程、对象等运行时概念以及相关的并发、同步、通信等问题。

    运用4+1视图方法:针对不同需求进行架构设计

    TOGAF9架构分类

    TOGAF9来对架构分类:

    由于不同架构方法论,定义的架构分类也不同,RUP4+1架构方法主要是以架构生命周期为视角进行描述,而TOGAF9按架构涉及内容维度来描述。因此我结合两者细分为业务架构、应用架构、数据架构、技术架构, 代码架构, 部署架构。

         

         业务架构是战略,应用架构是战术,技术架构是装备。其中应用架构承上启下,一方面承接业务架构的落地,另一方面影响技术选型。 熟悉业务,形成业务架构,根据业务架构,做出相应的应用架构,最后技术架构落地实施。

    1、业务架构(俯视架构)

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

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

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

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

         

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

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

    类似:

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

    应用架构图关键有2点:

    1、职责划分:   明确应用(各个逻辑模块或者子系统)边界
        1)逻辑分层
        2)子系统、模块定义。
        3)关键类。
    2、职责之间的协作:
     
     1)接口协议:应用对外输出的接口。
       2)协作关系:应用之间的调用关系。

        应用分层有两种方式:

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

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

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

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

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

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

    3、数据架构

    数据架构指导数据库的设计.  不仅仅要考虑开发中涉及到的数据库,实体模型,也要考虑物理架构中数据存储的设计。

    No.

    考虑的方面

    产出物

    工具

    说明

    1

    数据是集中还是分布存储的?如何考虑分布式存储?

    数据架构图

     

     

    2

    领域模型到数据库表的转换?表结构关系的设计?

    逻辑模型

    物理模型

    ER图

    Power Designer

    Visio

     

    3

    实体如何设计?充血模型和贫血模型?

    UML类图

     

     

    4

    使用什么数据库?关系型还是非关系型?

    选型结果

     

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

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

    代码架构主要定义内容:

    一、代码单元:
            1、配置设计
            2、框架、类库。
    二、代码单元组织:
           1、编码规范,编码的惯例。
           2、项目模块划分
           3、顶层文件结构设计,比如mvc设计。
           4、依赖关系

    No.

    考虑的方面

    产出物

    工具

    说明

    1

    分层结构设计

    分层架构图(开发架构图)

    各种绘图工具

    好的分层结构支持自动化测试

    2

    开发技术选项

    开发语言

    开发框架

    开发工具

     

    考虑商用产品、开源框架、自研框架

    3

    模块划分

    源码工程;Project目录结构;

    分包(分库)

     

     

    4

    开发规范

    开发/编码规范文档;

     

     

    5

    软件质量属性

    分析和决策结果

     

    考虑运行期和开发期软件质量属性,并权衡利弊进行决策。

    最好的样本是参考现有《阿里巴巴Java开发手册》。

     

    5、技术架构

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

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

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

     

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

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

    物理架构主要考虑硬件选择和拓扑结构,软件到硬件的映射,软硬件的相互影响。

     

    考虑的方面

    产出物

    工具

    说明

    1

    网络方面:网络拓扑;网络设备;安全机制

    拓扑图

    安全规范

     

     

    2

    性能方面:可靠性、可伸缩性

    需要什么样设备性能

     

     

    3

    部署方面:集中式还是分布式;组件部署

    部署图

     

     

     

     

    三、架构级别


    我们使用金字塔的架构级别来说明,上层级别包含下层:系统级、应用级、模块级、代码级。

    • 系统级,即整个系统内各部分的关系以及如何治理:分层。

    • 应用级,即单个应用的整体架构,及其与系统内单个应用的关系等。

    • 模块级,即应用内部的模块架构,如代码的模块化、数据和状态的管理等。

    • 代码级,即从代码级别保障架构实施。

    战略设计与战术设计

    基于架构金字塔,我们有了系统架构的战略设计与战术设计的完美结合:

    • 战略设计:业务架构用于指导架构师如何进行系统架构设计。

    • 战术设计:应用架构要根据业务架构来设计。

    • 战术实施:应用架构确定以后,就是技术选型。

     

    四、应用架构演进


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

     

    架构演进路程:单体应用->分布式应用服务化-> 微服务

     

    1、单体应用

    企业一开始业务比较简单,只应用某个简单场景,应用服务支持数据增删改查和简单的逻辑即可,单体应用可以满足要求。

    典型的三级架构,前端(Web/手机端)+中间业务逻辑层+数据库层。这是一种典型的Java Spring MVC或者Python Django框架的应用。其架构图如下所示: 

    针对单体应用,非功能性需求的做法:

       1、性能需求:使用缓存改善性能

       2、并发需求:使用集群改善并发

       3、读写分离:数据库地读写分离

      4、使用反向代理和cdn加速

      5、使用分布式文件和分布式数据库

    单体架构的应用比较容易部署、测试, 在项目的初期,单体应用可以很好地运行。然而,随着需求的不断增加, 越来越多的人加入开发团队,代码库也在飞速地膨胀。慢慢地,单体应用变得越来越臃肿,可维护性、灵活性逐渐降低,维护成本越来越高。下面是单体架构应用的一些缺点:

    复杂性高

    以一个百万行级别的单体应用为例,整个项目包含的模块非常多、模块的边界模糊、 依赖关系不清晰、 代码质量参差不齐、 混乱地堆砌在一起。可想而知整个项目非常复杂。 每次修改代码都心惊胆战, 甚至添加一个简单的功能, 或者修改一个Bug都会带来隐含的缺陷。

    技术债务: 随着时间推移、需求变更和人员更迭,会逐渐形成应用程序的技术债务, 并且越积 越多。“ 不坏不修”, 这在软件开发中非常常见, 在单体应用中这种思想更甚。 已使用的系统设计或代码难以被修改,因为应用程序中的其他模块可能会以意料之外的方式使用它。

    部署频率低: 随着代码的增多,构建和部署的时间也会增加。而在单体应用中, 每次功能的变更或缺陷的修复都会导致需要重新部署整个应用。全量部署的方式耗时长、 影响范围大、 风险高, 这使得单体应用项目上线部署的频率较低。 而部署频率低又导致两次发布之间会有大量的功能变更和缺陷修复,出错率比较高。

    可靠性差: 某个应用Bug,例如死循环、内存溢出等, 可能会导致整个应用的崩溃。

    扩展能力受限: 单体应用只能作为一个整体进行扩展,无法根据业务模块的需要进行伸缩。例如,应用中有的模块是计算密集型的,它需要强劲的CPU; 有的模块则是IO密集型的,需要更大的内存。 由于这些模块部署在一起,不得不在硬件的选择上做出妥协。

    阻碍技术创新: 单体应用往往使用统一的技术平台或方案解决所有的问题, 团队中的每个成员 都必须使用相同的开发语言和框架,要想引入新框架或新技术平台会非常困难。

    2、分布式

    随着业务深入,业务要求的产品功能越来越多,每个业务模块逻辑也都变得更加复杂,业务的深度和广度都增加,使得单体应用变得越来越臃肿,可维护性、灵活性逐渐降低,增加新功能开发周期越来越长,维护成本越来越高。

    这时需要对系统按照业务功能模块拆分,将各个模块服务化,变成一个分布式系统。业务模块分别部署在不同的服务器上,各个业务模块之间通过接口进行数据交互。

    该架构相对于单体架构来说,这种架构提供了负载均衡的能力,大大提高了系统负载能力,解决了网站高并发的需求。另外还有以下特点:

    降低了耦合度:把模块拆分,使用接口通信,降低模块之间的耦合度。

    责任清晰:把项目拆分成若干个子项目,不同的团队负责不同的子项目。

    扩展方便:增加功能时只需要再增加一个子项目,调用其他系统的接口就可以。

    部署方便:可以灵活的进行分布式部署。

    提高代码的复用性:比如Service层,如果不采用分布式rest服务方式架构就会在手机Wap商城,微信商城,PC,Android,iOS每个端都要写一个Service层逻辑,开发量大,难以维护一起升级,这时候就可以采用分布式rest服务方式,公用一个service层。

    缺点:系统之间的交互要使用远程通信,接口开发增大工作量,但是利大于弊。

     

    3、微服务

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

          微服务的特点:

    易于开发和维护: 一个微服务只会关注一个特定的业务功能,所以它业务清晰、代码量较少。 开发和维护单个微服务相对简单。而整个应用是由若干个微服务构建而成的,所以整个应用也会被维持在一个可控状态。

    单个微服务启动较快: 单个微服务代码量较少, 所以启动会比较快。

    局部修改容易部署: 单体应用只要有修改,就得重新部署整个应用,微服务解决了这样的问题。 一般来说,对某个微服务进行修改,只需要重新部署这个服务即可。

    技术栈不受限:在微服务架构中,可以结合项目业务及团队的特点,合理地选择技术栈。例如某些服务可使用关系型数据库MySQL;某些微服务有图形计算的需求,可以使用Neo4j;甚至可根据需要,部分微服务使用Java开发,部分微服务使用Node.js开发。

    微服务虽然有很多吸引人的地方,但它并不是免费的午餐,使用它是有代价的。使用微服务架构面临的挑战。

    运维要求较高:更多的服务意味着更多的运维投入。在单体架构中,只需要保证一个应用的正常运行。而在微服务中,需要保证几十甚至几百个服务服务的正常运行与协作,这给运维带来了很大的挑战。

    分布式固有的复杂性:使用微服务构建的是分布式系统。对于一个分布式系统,系统容错、网络延迟、分布式事务等都会带来巨大的挑战。

    接口调整成本高:微服务之间通过接口进行通信。如果修改某一个微服务的API,可能所有使用了该接口的微服务都需要做调整。

    重复劳动:很多服务可能都会使用到相同的功能,而这个功能并没有达到分解为一个微服务的程度,这个时候,可能各个服务都会开发这一功能,从而导致代码重复。尽管可以使用共享库来解决这个问题(例如可以将这个功能封装成公共组件,需要该功能的微服务引用该组件),但共享库在多语言环境下就不一定行得通了。

         
       

    五、衡量架构的合理性


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

    合理的架构设计:

    1、业务需求角度

    1、能解决当下业务需求和问题

    2、高效完成业务需求: 能以优雅且可复用的方式解决当下所有业务问题

    3、前瞻性设计: 能在未来一段时间都能以第2种方式满足业务,从而不会每次当业务进行演变时,导致架构翻天覆地的变化。

     

    2、非业务需求角度

    (一)、稳定性。指标:

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

    (二)、高效指标:

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

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

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

    (三)、安全指标

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

    六、常见架构误区


    ●开高走落不到实处

    ● 遗漏关键性约束与非功能需求

    ● 为虚无的未来埋单而过度设计

    ● 过早做出关键性决策

    ● 客户说啥就是啥成为传话筒

    ● 埋头干活儿缺乏前瞻性

    ● 架构设计还要考虑系统可测性

    ● 架构设计不要企图一步到位

    误区1——架构专门由架构师来做,业务开发人员无需关注

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

    误区2——架构师确定了架构蓝图之后任务就结束了

    架构不是“空中楼阁”,最终还是要落地的,但是架构师完全不去深入到第一线怎么知道“地”在哪?怎么才能落的稳稳当当。

    误区3——不做出完美的架构设计不开工

    世上没有最好架构,只有最合适的架构,不要企图一步到位。我们需要的不是一下子造出一辆汽车,而是从单轮车 --> 自行车 --> 摩托车,最后再到汽车。想象一下2年后才能造出的产品,当初市场还存在吗?

    误区4—— 为虚无的未来埋单而过度设计

    在创业公司初期,业务场景和需求边界很难把握,产品需要快速迭代和变现,需求频繁更新,这个时候需要的是快速实现。不要过多考虑未来的扩展,说不定功能做完,效果不好就无用了。如果业务模式和应用场景边界都已经比较清晰,是应该适当的考虑未来的扩展性设计。

     

    误区5——一味追随大公司的解决方案

    由于大公司巨大成功的光环效应,再加上从大公司挖来的技术高手的影响,网站在讨论架构决策时,最有说服力的一句话就成了“淘宝就是这么搞的”或者“腾讯 就是这么搞的”。

    大公司的经验和成功模式固然重要,值得学习借鉴,但如果因此而变得盲从,就失去了坚持自我的勇气,在架构演化的道路上迟早会迷路。

     

    误区6——为了技术而技术

    技术是为业务而存在的,除此毫无意义。在技术选型和架构设计中,脱离网站业务发展的实际,一味追求时髦的新技术,可能会将技术发展引入崎岖小道,架构之路越走越难。考虑实现成本、时间、人员等各方面都要综合考虑,理想与现实需要折中。

     

     

    七、架构书籍推荐


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

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

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

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

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

    3. 《架构即未来》

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

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

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

    5. 《聊聊架构》

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

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

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

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

     

    总结参考:

    《大型网站技术架构》、《软件架构师设计》《TOGAF9》

     

     

    展开全文
  • 为什么要报考系统架构设计师考试

    万次阅读 多人点赞 2019-08-02 17:03:09
    一、强迫自己,去系统学习软件架构设计的理论,追踪业界架构设计的发展动态。去学习的动力有很多,如为了兴趣,为了工作,为了职位升迁,为了大幅提升薪水等。其实,为了应付考试,通过考试,也是学习知识的一种很好...

       为什么要报考系统架构师考试  

        最近一年多,很多朋友来信,问我什么要报考系统架构设计师考试。为什么参加这个考试,这个考试有用吗?对自己的职业会带来什么好处?我想有以下几个方面:

    一、强迫自己,去系统学习软件架构设计的理论,追踪业界架构设计的发展动态。去学习的动力有很多,如为了兴趣,为了工作,为了职位升迁,为了大幅提升薪水等。其实,为了应付考试,通过考试,也是学习知识的一种很好的方法。尤其,对自律能力不是很好的同学;

    二、系统架构师考试,作为计算机技术与软件专业技术资格(水平)考试系列的最高级别专业考试,是国家认可的。如果通过,至少可以说明以下几点:

     1.这是国家级别计算机领域最高级别的考试,难度程度不低于其他行业的司法考试,会计考试等,如果您通过了,那么说明您自己的智商至少不差,还是有一定学习能力,对付考试,还算有一套;

     2.在同级别的高级资格里,系统架构师同系统分析师、网络规划设计师、信息系统项目管理师相比较而言,技术难度是最高,技术难度更高点,知识面更广阔点,专业深度很深些,更偏重技术研发;

     3.至少说明自己还在追求进步,想在专业上有所突破,想参加这个考试;

     4.参加这个考试,9点钟考试,6点就要起床,因为考点都在荒郊野外,偏离市中心;

    十一月大冬天的起个大早上,北风那个吹呀,也是很苦的。

     5.下午案例分析,怎么也要有论据,有观点,紧扣题意,总不能离题万里,答非所问,否则怎么通过下午案例考试,获得45分;

     6.下午论文考试,能够在短短1个半小时时间里,写至少2500个汉字,也不简单,尤其现在大家天天用电脑,用键盘敲字,不提笔忘字,能文思泉涌,逻辑清晰,条理清晰,写出来这篇论文,有论据,有观点,还能够通过,也算点人才吧!

    三、架构师理论,自成一派,架构模式,思维理念,对工作、对生活、对职业很有帮助。我们常说,思想决定行动,思想决定出路,思想决定命运,思想决定未来。架构设计思想,该是多么的重要的。学习架构设计的思想,是有百利无一害的。

    四、架构师岗位,作为职业,研发领域的最高端岗位,学习架构理论,参加架构师工业和信息化部、人力资源和社会保障部主持的系统架构设计师考试,与也可以站在理论界、学术界的前沿,洞悉架构设计的本质,行业发展脉络;

    五、这个考试有用吗?我想说,你上了大学有用吗?你考取了研究所有用吗?你获取了博士学位有用吗?大家一定也知道很多大学生滥竽充数,水平低下,博士能力平平,招摇过市。想获取一纸文凭,就衣食无忧,高高在上,丰衣足食,衣食无忧,这怎么可能呢?重要的是自己真材实料,货真价实。文凭代表的是知识,能做事,能解决实际问题代表是能力。这是两码事。这个架构师证书,又何尝不是这样呢?

    六、在事业单位,国企单位,还是挺管用,至少在评定副高、高级职称的时候用得上;

    七、通过了国家的系统架构师考试,至少你敢在求职简历上写,你是系统架构师。为什么呢?大家拿了大学文凭,博士学位,不都在简历上写着“大学生”、“博士”。哪怕读大学,天天旷课,打游戏,交女朋友。但是,大学文凭,博士学位,没偷没抢,没蒙没骗,正儿八经的按照学校规定获取了学分,提交论文,获取的。所以,咱这个系统架构师,也是光明正大的考试通过的。

    八、自己可以理直气壮的争取系统架构师的职位,高端岗位,毕竟咱有较为雄厚的架构师的理论基础,有理论,有方法。

    九、有朝一日,也可以参与软考培训行业,做IT高端培训,想做系统架构设计培训,哪可必须要有国家级的系统架构师证书哟!张友生搞得希赛IT教育培训,就是以软考培训起家的,也搞得有模有样,风水水起;想必参加软考的童靴,一定买过张友生老师主编的软考书籍。多一条路,多一个活法。老人常说,艺多不压身。

    十、如果自己通过了,千万别把它太当回事,别以为自己真是系统架构师,具有系统架构师能力和学识了。别以为获取博士学位,就真是博士了。一个道理。这是万里长征的第一步。这是行走在系统架构师路上的一个垫脚石。路漫漫其修远兮,吾将上下而求索。

    赋诗一首:

    附1:小虎软考微信公众号:2019跟着小虎玩着去软考

     

    展开全文
  • 微信技术总监分享架构设计高清完整PDF版

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

    万次阅读 2018-09-29 17:05:51
    那接下来就是如何着手开始做架构设计。 一、如何开始设计一个架构:方式方法 架构不是像平常写代码一样,对就是对,错就是错,它并无对错之分,是一个取舍的过程。当我们从0开始做架构的时候,的确是比较困难。...
  • 对软件架构设计的一些总结和理解

    万次阅读 多人点赞 2015-09-06 22:28:18
    1. 软件架构设计的What & Why ● 啥是软件架构(Software Architecture)? 软件架构是指在一定的设计原则基础上,从不同角度对组成系统的各部分进行搭配和安排,形成系统的多个结构而组成架构,它包括该系统...
  • 架构设计之CS架构

    千次阅读 2019-04-23 20:57:05
    架构设计之CS架构
  • 课程主体部分从软件架构体系结构、架构设计、技术体系等角度出发,详细介绍了架构师区别于一般开发人员所需要掌握的架构设计方法论与相关实践,包括架构风格与模式、领域驱动设计、类与框架设计、分布式系统架构设计...
  • 高性能微服务架构设计模式

    千人学习 2019-12-26 17:34:19
    本课程是对分布式微服务架构设计模式进行讲解,以亿级QPS的电商网站为例对常见的技术架构进行分析,从高性能,高可用的角度比较各种方案的优劣点,重点讲解使用CQRS模式怎么进行高性能的微服务架构设计,读者学习本...
  • 架构设计——架构知识体系

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

    万人学习 2015-10-10 09:20:33
    目前很多开发者对于游戏架构设计一无所知,只是简单的把脚本与对象进行挂接,导致在后期开发中,版本维护,功能扩展非常不方便,现在网上出现了各种版本的热更新实现,比如Lua,JS,C#Light等, 该框架设计技术...
  • 软件架构设计---架构设计

    千次阅读 2018-09-17 21:46:29
    实现软件质量属性的战术,这些战术可以看做设计的... 通过架构模式,架构设计师可以借鉴和复用他人的经验,看看类似的问题别人是如何解决的。但不要把模式看成是一个硬性的解决方法,它只是一种解决问题的思路。...
  • 微服务架构设计模式与CAP定理

    万次阅读 热门讨论 2020-09-22 23:01:09
    微服务架构设计模式与CAP定理 前言        hello 大家好,我是一名Java后端开发的程序猿。由于国庆假期已经来了,所以我打算把这一星期的时间用来好好提升下自己的技术水平。...
  • 架构设计(8)—高可用架构设计

    千次阅读 2019-01-14 17:58:37
    高可用架构设计总结: 前言:海恩法则和墨菲定律 海恩法则 · 事故的发生是量的积累的结果。 · 再好的技术、再完美的规章 , 在实际操作层面也无法取代人自身的素质和责任心 。 墨菲定律 · 任何事情都没有...
  • 物联网平台架构设计

    万次阅读 多人点赞 2017-09-11 14:13:28
    用户如何管理,数据包如何解析,大数据如何展示等也是物联网模块中非常重要的部分,所以作者就根据自身工作中总结出来的建构在云端的物联网平台基本架构分享给大家,并基于此架构如何一步一步来开发
  • 架构设计的本质

    千次阅读 2020-10-12 15:45:24
    本文尝试从更高视角重新审视架构设计的工作,把架构设计的上升到系统设计的立体空间去探索,最终勾勒出系统设计的全域知识体系。作者 | 编程原理林振华【问题】 什么是系统设计,系统设计的核心是什么? ...
  • 微服务架构设计实践 目 次1 序言2 微服务3 软件架构设计思想4 微服务架构设计实践4.1 项目概述4.2 架构准备阶段4.3 概念架构阶段4.4 细化架构阶段4.4.1 业务架构4.4.2 数据架构4.4.3 应用架构4.4.4 技术架构4.4.5 ...
  • 架构设计(6)-架构需求分析

    万次阅读 2018-07-06 15:17:57
    架构设计需求分析: 主要目的是明确架构要解决当前什么问题, 先调研需求方的诉求。 如果公司的架构部自high,做一些根本没有人使用的框架,组件,系统: 以“晋升”为目的的架构设计都应该拉出去祭天。 脱离业务的...
  • 架构设计之如何写架构设计说明书

    千次阅读 2015-06-04 13:55:09
    架构设计是需求分析到软件实现的桥梁,...作为一个架构师,我想尝试一下根据这三个过程对不同能力需要,写一次系列文章,包括《架构设计三部曲之如何写架构设计说明书》、《架构设计三部曲之如何评审架构设计说明书》以
  • 模块化架构设计

    千次阅读 2020-09-02 18:10:39
    架构设计是一个不断演变的过程,当项目较小,或者项目刚刚起步的阶段,我们往往不需要关注架构设计,只有当软件膨胀到一定程度,我们才会针对当前业务,设计出适合当前阶段的架构。所以有的项目就会出现不断膨胀,...
  • 开源大数据技术架构设计

    万人学习 2015-09-23 11:19:44
    主讲: 钱广锐(IBM研究员/技术讲师/教授) 苏再卿(IBM开发组长/工程师/技术讲师) 【课程主题】 开源大数据技术架构设计
  • 软件架构设计---软件架构概述

    万次阅读 2018-09-17 21:25:54
    通俗地讲,软件架构设计就是软件系统的“布局谋篇”。  人们在软件工程实践中,逐步认识到了软件架构的重要性,从而开辟了一个崭新的研究领域。软件架构的研究内容主要涉及软件架构描述、软件架构设计、软件架构...
  • 架构设计方法

    千次阅读 2018-06-02 10:13:08
    1 基本概念和目的架构设计的目的是为了解决系统复杂度带来的问题,并不是要面面俱到,不需要每个架构都具备高性能、高可用、高扩展等特点,而是要识别出实际业务实际情况的复杂点,然后有有针对性地解决问题,即:...
  • 架构实战:架构设计文档模板

    千次阅读 2019-06-11 11:24:14
    在前面的专栏里,有同学留言说想看看具体的架构设计文档。由于信息安全的原因,再加上稍微复杂的系统,设计文档都是几十页,因此专栏无法直接给出详细的文档案例。但我认为提供一个架构设计文档模板还是很有必要的,...
  • 在不同的架构设计方法中出现的软件架构视图种类很多,本文介绍最常用的两种架构视图——逻辑架构视图和物理架构视图,并通过具体案例的分析说明如何运用它们进行架构设计。 当观察和描述事物大局的时候,逻辑架构和...
  • 绪论本文打算探讨一下软件架构设计的一些设计原则与经过实践验证的设计模式。 前端(MVC模式)和后端(接口层-业务层-助手层)的分层设计经过了几十年大量软件的证明。分层的思想,就是每一个层次专注做一件事情。每...
  • 架构设计的目的

    千次阅读 2019-05-21 22:37:23
    架构设计的误区 关于架构设计的目的,常见的误区有: •因为架构很重要,所以要做架构设计 这是一句正确的废话,架构是很重要,但架构为何重要呢? 例如:不做架构设计系统就跑不起来么? 其实不然,很多朋友尤其是...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 132,180
精华内容 52,872
关键字:

架构设计