精华内容
下载资源
问答
  • 数据驱动型企业服务研究分析 数据驱动型企业概念 以数据生产要素驱动经营管理实现持续增长和创新发展 从农业经济到工业经济生产要素经历了由土地劳动力向资本技术及管理等的演进数字经济时代催生了以大数据为 代表...
  • 数据驱动型企业服务研究分析 数据驱动型企业概念 土地 可复制 劳动力 农业经济时代 资本 技术 工业经济时代 管理 传统生产要素 新型生产要素 数字经济时代 生产要素范畴拓宽 可共享 无限增长和供给 VS 数据 以数据...
  • 如何识别和整合数据源以及选择合适的技术来支持数据整合,成为了企业当下急需面对的问题。而且对企业而言,数据决策已经不再是业务的副产品,而是适应社会的生存能力,也是成功的关键因素。企业需要建立可信且统一的...


    处理器在更新换代,

    企业也面临着如何转型的巨大挑战。

    老化的处理器会被遗弃,

    落后的企业也同样会被淘汰。


    如何识别和整合数据源

    以及选择合适的技术来支持数据整合,

    成为了企业当下急需面对的问题。

    而且对企业而言,

    数据决策已经不再是业务的副产品,

    而是适应社会的生存能力,

    也是成功的关键因素。


    企业需要建立可信且统一的基础设施,来高效地存储数据、快速传输数据,并以极快的速度分析数据,以便企业能够随时随地从广泛分布的数据中获取所需的商业洞察。


    这对许多 IT 部门来说,似乎有些要求过高,但通过业务部门与 IT 部门之间的协作,实现数据驱动型企业可以从下面5步入手:


    第一步:搞清企业所处数据分析的阶段


    如果企业在从数据中获得价值与洞察方面发展缓慢,很有可能会在竞争中处于劣势。为此,按照下图评估自身所处的数据分析阶段及向用户交付的价值十分重要。


    分析成熟度的各个阶段


    第二步:了解业务驱动因素和转型成果


    由业务部门主导、IT 部门协助确定业务优先级,并制定数据战略。


    在此过程中,IT 主管可以基于企业技术平台的现状和特点,通过与高层管理人员开展交流,分析确定优先级;参考业内其他企业案例,提供一些洞察和意见;通过整体业务案例来证明采用数据驱动型方法的经济效益;宣传展示数据分析实践在公司中的成功应用。


    第三步:创建以数据为中心的基础架构


    确定了目标和当前的就绪状态后,接下来,IT 部门就可以规划转型所需的基础设施。从技术角度来看,首要的任务是建立企业需要的数据架构。这其中很大一部分是思考如何根据企业所设定的业务优先级,更高效地使用现有资产。


    企业应从分布式数据模型和架构着手,之后再根据新的业务模式和机会,考虑如何排定投资的优先顺序以及如何提供企业所需的基础设施。


    如今有各种平台可以帮助企业通过先进的数据分析和机器学习提高预测能力和实时洞察力。然而,这并不是重点,重点是要拥有合适的工具箱,并且知道在哪种情况下使用哪个工具。


    这个工具箱可能包含各种技术和服务:公有的和私有的、内部的和合作伙伴的、现代的和传统的,基于服务平台的交付还是 API 驱动的服务层(见下图)。


    数据分析解决方案堆栈


    第四步:创建 PoC 为双模态未来做好准备


    一旦奠定了坚实的基础,您就可以通过支持性概念验证(PoC)对计划进行测试。概念验证的目的不仅是测试您的模型和想法,也是为企业设定一个双模态未来的场景。但企业既不能同时解决所有数据分析基础设施问题,也不能一夜之间完成文化转型。因此,概念验证应由业务部门主导、符合战略业务目标、有明确的成功标准和各方都认可的 PoC,同时具备高可操作性。


    第五步:推动并专注服务交付和业务价值


    最后一步,则是推动创建其实现长期目标所需的数据平台。如果在此基础上部署英特尔至强可扩展处理器,借助其最新的数据分析功能,也可以进一步投资于其他工具,以便使更多业务从数据分析中获益。


    作为计算力创新的引领者,英特尔不仅可以提供具体的产品技术,还能够针对固态存储、开源工具、内存分析、分析工具与框架等需求给到有关构建、扩展和论证数据分析基础设施的建议,不仅停留在技术创新与支持层面,而是更全面的在各个层次给予支持,加速企业转型变革。


    我们正处于数字时代。若要想获得技术变革带来的商业益处,业务部门和 IT 团队必须学习如何就专门的数据分析计划开展合作。以数据为中心的企业将数据分析视为业务各个方面的核心,这正是企业取得成功的关键所在。

    展开全文
  • 大型网站技术架构

    万次阅读 2016-11-28 11:22:28
    第一篇:概述传统的企业应用系统主要面对的技术挑战是处理复杂凌乱、千变万化的所谓业务逻辑,而大型网站主要面对的技术挑战是处理超大量的用户访问和海量的数据处理;前者的挑战来自功能性需求,后者的挑战来自非...

    第一篇:概述

    传统的企业应用系统主要面对的技术挑战是处理复杂凌乱、千变万化的所谓业务逻辑,而大型网站主要面对的技术挑战是处理超大量的用户访问和海量的数据处理;前者的挑战来自功能性需求,后者的挑战来自非功能性需求;功能性需求也许还有“人月神话”聊以自慰,通过增加人手解决问题,而非功能需求大多是实实在在的技术难题,无论有多少工程师,做不到就是做不到。

    “好的设计绝对不是模仿、不是生搬硬套某个模式,而是在对问题深刻理解之上的创造与创新,即使是‘微创新’,也是让人耳目一新的似曾相识。

    京东促销不能购买的例子

    能够正常访问购物车,却不能成功购买,问题应该是出在订单系统,B 2C网站生成一个订单需要经历扣减库存、扣减促销资源、更新用户账户等一系列操作这些操作大多是数据库事务操作,没有办法通过缓存等手段来减轻数据库服务器负载压力,如果事前没有设计好数据库伸缩性架构,那么京东的技术团队将遇到一个大麻烦

    1.大型网站架构演化

    如何打造一个高可用、高性能、易扩展、可伸缩且安全的网站?如何让网站随应用所需灵活变动,即使是山寨他人的产品,也可以山寨的更高、更快、更强,一年时间用户数从零过亿呢?

    1.1大型网站软件系统的特点

    有以下特点:

    1.高并发,大流量
    2.高可用:系统24小时不间断服务
    3.海量数据
    4.用户分布广泛,网络情况复杂
    5.安全环境恶劣
    6.需求快速变更,发布频繁
    7.渐进式发展

    1.2大型网站架构演化发展历程

    1.初始阶段的网站架构

    应用程序,数据库,文件等所有的资源都在一台服务器上。

    2.应用服务和数据服务分离

    应用和数据分离后整个网站使用三台服务器:应用服务器,文件服务器和数据库服务器。如下图所示:

    这三台服务器对硬件资源的要求各不相同:

    1.应用服务器需要处理大量的业务逻辑,因此需要更快更强大的CPU
    2.数据库服务器需要快速磁盘检索和数据缓存,因此需要更快的硬盘和更大的内存
    3.文件服务器需要存储大量用户上传的文件,因此需要更大的磁盘

    随着用户逐渐增多,网站又一次面临挑战:数据库压力太大导致访问延迟,进而影响整个网站的性能,用户体验受到影响。

    3.访问缓存改善网站性能

    网站访问特点和现实世界的财富分配一样遵循二八定律:80%的业务访问集中在20%的数据上

    网站使用的缓存可以分为两种:缓存在1.应用服务器上的本地缓存和缓存在专门的2.分布式缓存服务器上的远程缓存。本地缓存的访问速度更快一些,但是受应用服务器内存限制,其缓存数据量有限,而且会出现和应用程序争用内存的情况。远程分布式缓存可以使用集群的方式,部署大内存的服务器作为专门的缓存服务器,可以在理论上做到不受内存容量限制的缓存服务,如图:

    使用缓存后,数据访问压力得到有效缓解,但是单一应用服务器能够处理的请求连接有限,在网站高峰期,应用服务器成为整个网站的瓶颈

    4.使用应用服务器集群改善网站的并发处理能力

    使用集群是网站解决高并发、海量数据问题的常用手段。当一台服务器的处理能力、存储空间不足时,不要企图去换更强大的服务器,对大型网站而言,不管多么强大的服务器,都满足不了网站持续增长的业务需求。这种情况下,更恰当的做法是增加一台服务器分担原有服务器的访问及存储压力。架构如图:

    5.数据库读写分离

    目前大部分的主流数据库都提供主从热备功能,通过配置两台数据库主从关系,可以将一台数据库服务器的数据更新同步到另一台服务器上。网站利用数据库的这一功能,实现数据库读写分离,从而改善数据库负载压力。如图:

    6.使用反向代理和CDN加速网站响应

    CDN和反向代理的基本原理都是缓存,区别在于CDN部署在网络提供商的机房,使用户在请求网站服务时,可以从距离自己最近的网络提供商机房获取数据;而反向代理则部署在网站的中心机房,当用户请求到达中心机房后,首先访问的服务器是反向代理服务器,如果反向代理服务器中缓存着用户请求的资源,就将其直接返回给用户。架构如图:

    使用CDN和反向代理的目的是尽早返回数据给用户,一方面加快用户访问速度,另一方面也减轻了后端服务器的负载压力。

    7.使用分布式文件系统和分布式数据库系统

    分布式数据库是网站数据库拆分的最后手段,只有在单表数据规模非常庞大的时候才使用。不到不得已时,网站更常用的数据库拆分手段是业务分库,将不同业务的数据库部署在不同的物理服务器上

    8.使用NoSQL和搜索引擎

    9.业务拆分

    10.分布式服务

    既然每一个应用系统都需要执行许多相同的业务操作,比如用户管理、商品管理等,那么可以将这些共用的业务提取出来,独立部署。由这些可复用的业务连接数据库,提供共用业务服务,而应用系统只需要管理用户界面,通过分布式服务调用共用业务服务完成具体业务操作,如图:

    1.4网站架构设计误区

    误区:

    1.一味追随大公司的解决方案
    2.为了技术而技术
    3.企图用技术解决所有问题

    比如说12306网站:

    12306真正的问题其实不在于它的技术架构,而在于它的业务架构:12306根本就不应该在几亿中国人一票难求的情况下以窗口售票的模式在网上售票(零点开始出售若干天后的车票)。12306需要重构的不仅是它的技术架构,更重要的是它的业务架构:调整业务需求,换一种方式卖票,而不要去搞促销秒杀这种噱头式的游戏。

    后来证明12306确实是朝这个方向发展的:在售票方式上引入了排队机制、整点售票调整为分时段售票。其实如果能控制住并发访问的量,很多棘手的技术问题也就不是什么问题了。

    2.大型网站架构模式

    关于什么是模式,这个来自建筑学的词汇是这样定义的:“每一个模式描述了一个在我们周围不断重复发生的问题及该问题解决方案的核心。这样,你就能一次又一次地使用该方案而不必做重复工作”。模式的关键在于模式的可重复性,问题与场景的可重复性带来解决方案的可重复使用

    2.1网站架构模式

    1.分层

    分层是企业应用系统中最常见的一种架构模式,将系统在横向维度上切分成几个部分,每个部分负责一部分相对比较单一的职责,然后通过上层对下层的依赖和调用组成一个完整的系统。

    分层结构在计算机世界中无处不在,网络的7层通信协议是一种分层结构;计算机硬件、操作系统、应用软件也可以看作是一种分层结构。在大型网站架构中也采用分层结构,将网站软件系统分为1.应用层2.服务层3.数据层,如表:

    但是分层架构也有一些挑战,就是必须合理规划层次边界和接口,在开发过程中,严格遵循分层架构的约束,禁止跨层次的调用(应用层直接调用数据层)及逆向调用(数据层调用服务层,或者服务层调用应用层)。

    2.分割

    对软件进行纵向切分

    3.分布式

    对于大型网站,分层和分割的一个主要目的是为了切分后的模块便于分布式部署,即将不同模块部署在不同的服务器上,通过远程调用协同工作。分布式意味着可以使用更多的计算机完成同样的功能,计算机越多,CPU、内存、存储资源也就越多,能够处理的并发访问和数据量就越大,进而能够为更多的用户提供服务。

    在网站应用中,常用的分布式方案有如下几种:

    1.分布式应用和服务

    将分层和分割后的应用和服务模块分布式部署,除了可以改善网站性能和并发性、加快开发和发布速度、减少数据库连接资源消耗外;还可以使不同应用复用共同的服务,便于业务功能扩展。

    2.分布式静态资源

    网站的静态资源如JS, CSS, Logo图片等资源独立分布式部署,并采用独立的域名,即人们常说的动静分离。静态资源分布式部署可以减轻应用服务器的负载压力;通过使用独立域名加快浏览器并发加载的速度;由负责用户体验的团队进行开发维护有利于网站分工合作,使不同技术工种术业有专攻。

    3.分布式数据和存储

    大型网站需要处理以P为单位的海量数据,单台计算机无法提供如此大的存储空间,这些数据需要分布式存储。除了对传统的关系数据库进行分布式部署外,为网站应用而生的各种NoSQL产品几乎都是分布式的。

    4.分布式计算

    目前网站普遍使用Hadoop及其M apR educe分布式计算框架进行此类批处理计算,其特点是移动计算而不是移动数据,将计算程序分发到数据所在的位置以加速计算和分布式计算。

    4.集群

    5.缓存

    缓存就是将数据存放在距离计算最近的位置以加快处理速度。缓存是改善软件性能的第一手段,现代CPU越来越快的一个重要因素就是使用了更多的缓存,在复杂的软件设计中,缓存几乎无处不在。大型网站架构设计在很多方面都使用了缓存设计。

    使用缓存的例子:CDN,反向代理,本地缓存,分布式缓存。

    使用缓存有两个前提条件

    1.数据访问热点不均衡。
    2.数据在某个时间段内有效,不会很快过期,否则缓存的数据就会因已经失效而产生脏读,影响了结果的正确性。

    6.异步

    7.冗余

    8.自动化

    9.安全

    2.2架构模式在新浪微博中的应用

    新浪微博的架构在较短的时间内几经重构,最终形成了现在的架构:

    系统分为三个层次,最下层是基础服务层,提供数据库,缓存,存储,搜索等数据服务,以及其他一些基础技术服务,这些服务支撑了整个新浪微博的海量数据和高并发访问,是整个系统的技术基础。

    中间层是平台服务和应用服务层,新浪微博的核心服务是微博、关系和用户,它们是新浪微博业务大厦的支柱。这些服务被分割为独立的服务模块,通过依赖调用和共享基础数据构成新浪微博的业务基础。

    最上层是API和新浪微博的业务层,各种客户端(包括Web网站)和第三方应用,通过调用API集成到新浪微博的系统中,共同组成一个生态系统。

    在新浪微博的早期架构中,微博发布使用同步推模式,用户发表微博后系统会立即将这条微博插入到数据库所有粉丝的订阅列表中,当用户量比较大时,特别是明星用户发布微博时,会引起大量的数据库写操作,超出数据库负载,系统性能急剧下降,用户响应延迟加剧。后来新浪微博改用异步推拉结合的模式,用户发表微博后系统将微博写入消息队列后立即返回,用户响应迅速,消息队列消费者任务将微博推送给所有当前在线粉丝的订阅列表中,非在线用户登录后再根据关注列表拉取微博订阅列表。

    3.大型网站核心架构要素

    关于什么是架构,一种比较通俗的说法是“最高层次的规划,难以改变的决定”,这些规划和决定奠定了事物未来发展的方向和最终的蓝图。

    3.1性能

    性能是网站的一个重要指标,除非是没得选择(比如只能到www.12306.cn这一个网站上买火车票),否则用户无法忍受一个响应缓慢的网站。一个打开缓慢的网站会导致严重的用户流失,很多时候网站性能问题是网站架构升级优化的触发器。可以说性能是网站架构设计的一个重要方面,任何软件架构设计方案都必须考虑可能会带来的性能问题。

    也正是因为性能问题几乎无处不在,所以优化网站性能的手段也非常多,从用户浏览器到数据库,影响用户请求的所有环节都可以进行性能优化。

    浏览器端,可以通过浏览器缓存、使用页面压缩、合理布局页面、减少Cookie传输等手段改善性能。

    还可以使用CDN,将网站静态内容分发至离用户最近的网络服务商机房,使用户通过最短访问路径获取数据。可以在网站机房部署反向代理服务器,缓存热点文件,加快请求响应速度,减轻应用服务器负载压力。

    应用服务器端,可以使用服务器本地缓存和分布式缓存,通过缓存在内存中的热点数据处理用户请求,加快请求处理过程,减轻数据库负载压力。

    也可以通过异步操作将用户请求发送至消息队列等待后续任务处理,而当前请求直接返回响应给用户。

    在网站有很多用户高并发请求的情况下,可以将多台应用服务器组成一个集群共同对外服务,提高整体处理能力,改善性能。

    代码层面,也可以通过使用多线程、改善内存管理等手段优化性能。

    在数据库服务器端,索引、缓存、SQL优化等性能优化手段都已经比较成熟。而方兴未艾的NoSQL数据库通过优化数据模型、存储结构、伸缩特性等手段在性能方面的优势也日趋明显。

    衡量网站性能有一系列指标,重要的有响应时间TPS系统性能计数器等,通过测试这些指标以确定系统设计是否达到目标。这些指标也是网站监控的重要参数,通过监控这些指标可以分析系统瓶颈,预测网站容量,并对异常指标进行报警,保障系统可用性。

    3.2可用性

    网站高可用的主要手段是冗余,应用部署在多台服务器上同时提供访问,数据存储在多台服务器上互相备份,任何一台服务器宕机都不会影响应用的整体可用,也不会导致数据丢失。

    对于应用服务器而言,多台应用服务器通过负载均衡设备组成一个集群共同对外提供服务,任何一台服务器宕机,只需把请求切换到其他服务器就可实现应用的高可用,但是一个前提条件是应用服务器上不能保存请求的会话信息。否则服务器宕机,会话丢失,即使将用户请求转发到其他服务器上也无法完成业务处理

    3.3伸缩性

    衡量架构伸缩性的主要标准就是是否可以用多台服务器构建集群,是否容易向集群中添加新的服务器。加入新的服务器后是否可以提供和原来的服务器无差别的服务。集群中可容纳的总的服务器数量是否有限制。

    3.4扩展性

    不同于其他架构要素主要关注非功能性需求,网站的扩展性架构直接关注网站的功能需求。网站快速发展,功能不断扩展,如何设计网站的架构使其能够快速响应需求变化,是网站可扩展架构主要的目的。

    网站可伸缩架构的主要手段是事件驱动架构分布式服务

    事件驱动架构在网站通常利用消息队列实现,将用户请求和其他业务事件构造成消息发布到消息队列,消息的处理者作为消费者从消息队列中获取消息进行处理。通过这种方式将消息产生和消息处理分离开来,可以透明地增加新的消息生产者任务或者新的消息消费者任务。

    分布式服务则是将业务和可复用服务分离开来,通过分布式服务框架调用。新增产品可以通过调用可复用的服务实现自身的业务逻辑,而对现有产品没有任何影响。可复用服务升级变更的时候,也可以通过提供多版本服务对应用实现透明升级,不需要强制应用同步变更。

    3.5安全性

    3.6小结

    性能可用性伸缩性扩展性安全性是网站架构最核心的几个要素。

    第二篇:架构

    4.瞬时响应:网站的高性能架构

    网站性能是客观的指标,可以具体体现到响应时间、吞吐量等技术指标,同时也是主观的感受,而感受则是一种与具体参与者相关的微妙的东西,用户的感受和工程师的感受不同,不同的用户感受也不同。

    2.性能测试指标

    主要指标有响应时间,并发数,吞吐量,性能计数器等:

    1.响应时间

    指应用执行一个操作需要的时间,包括从发出请求开始收到最后响应数据所需要的时间。响应时间是系统最重要的性能指标,直观地反映了系统的“快慢”。

    2.并发数

    指系统能够同时处理请求的数目,这个数字也反映了系统的负载特性。

    注意厘清数量关系

    网站系统用户数>>网站在线用户数>>网站并发用户数

    3.吞吐量

    指单位时间内系统处理的请求数量,体现了系统的整体处理能力。TPS(每秒事务数)是吞吐量的一个常用量化指标,此外还有HPS(每秒HTTP请求数)、QPS(每秒查询数)等。

    系统吞吐量系统并发数,以及响应时间的关系可以形象地理解为高速公路的通行状况:

    吞吐量是每天通过收费站的车辆数目(可以换算成收费站收取的高速费),并发数是高速公路上的正在行驶的车辆数目,响应时间是车速。

    车辆很少时,车速很快,但是收到的高速费也相应较少;随着高速公路上车辆数目的增多,车速略受影响,但是收到的高速费增加很快;随着车辆的继续增加,车速变得越来越慢,高速公路越来越堵,收费不增反降;如果车流量继续增加,超过某个极限后,任何偶然因素都会导致高速全部瘫痪,车走不动,费当然也收不着,而高速公路成了停车场(资源耗尽)。

    4.性能计数器

    System Load即系统负载,指当前正在被CPU执行和等待被CPU执行的进程数目总和,是反映系统忙闲程度的重要指标。多核CPU的情况下,完美情况是所有CPU都在使用,没有进程在等待处理,所以Load的理想值是CPU的数目。当Load值低于CPU数目的时候,表示CPU有空闲,资源存在浪费;当Load值高于CPU数目的时候,表示进程在排队等待CPU调度,表示系统资源不足,影响应用程序的执行性能。在Linux系统中使用top命令查看,该值是三个浮点数,表示最近1分钟,10分钟,15分钟的运行队列平均进程数。

    3.性能测试方法

    性能测试是一个总称,具体可以细分为性能测试负载测试压力测试稳定性测试

    4.性能优化方法

    定位产生性能问题的具体原因后,就需要进行性能优化,根据网站分层架构,可分为1.Web前端性能优化2.应用服务器性能优化、**3.存储服务器性能优化**3大类。

    4.2Web前端性能优化

    1.浏览器访问优化

    1.减少http请求

    HTTP协议是无状态的应用层协议,意味着每次HTTP请求都需要建立通信链路、进行数据传输,而在服务器端,每个HTTP都需要启动独立的线程去处理。这些通信和服务的开销都很昂贵,减少HTTP请求的数目可有效提高访问性能。

    减少HTTP的主要手段是合并CSS、合并JavaScript、合并图片。将浏览器一次访问需要的JavaScript、CSS合并成一个文件,这样浏览器就只需要一次请求。图片也可以合并,多张图片合并成一张,如果每张图片都有不同的超链接,可通过CSS偏移响应鼠标点击操作,构造不同的URL。

    2.使用浏览器缓存

    对于一个网站而言,CSS,JS,logo,图标这些静态资源文件更新的频率都比较低,而这些文件又几乎是每次HTTP请求都需要的,如果将这些文件缓存在浏览器中,可以极好地改善性能。通过设置HTTP头中的Cache-Control和Expires的属性,可设定浏览器缓存,缓存时间可以是数天,甚至是几个月

    3.启用压缩

    4.CSS放在页面最上面,JS放在页面最下面

    5.减少Cookie传输

    一方面,Cookie包含在每次请求和响应中,太大的C ookie会严重影响数据传输,因此哪些数据需要写入C ookie需要慎重考虑,尽量减少C ookie中传输的数据量。另一方面,对于某些静态资源的访问,如CSS、Script等,发送C ookie没有意义,可以考虑静态资源使用独立域名访问,避免请求静态资源时发送C ookie,减少C ookie传输的次数

    2.CDN加速

    CDN能够缓存的一般是静态资源,如图片、文件、CSS、Script脚本、静态网页等,但是这些文件访问频度很高,将其缓存在CDN可极大改善网页的打开速度。

    3.反向代理

    4.3应用服务器性能优化

    应用服务器就是处理网站业务的服务器,网站的业务代码都部署在这里,是网站开发最复杂,变化最多的地方,优化手段主要是缓存,集群,异步等。

    1.分布式缓存

    缓存的基本原理

    缓存指将数据存储在相对较高访问速度的存储介质中,以供系统处理。一方面缓存访问速度快,可以减少数据访问的时间,另一方面如果缓存的数据是经过计算处理得到的,那么被缓存的数据无需重复计算即可直接使用,因此缓存还起到减少计算时间的作用。

    不合理使用缓存的例子:

    1.频繁修改的数据

    一般来说,数据的读写比在2:1以上,即写入一次缓存,在数据更新前至少读取两次,缓存才有意义。在实践中,这个比例通常非常高,例如新浪热门微博,缓存以后可能会被读取数百万次。

    2.没有热点的访问

    3.数据不一致与脏读

    一般会对缓存的数据设置失效时间,一旦超过失效时间,就要从数据库中重新加载。因此应用要容忍一定时间的数据不一致,如卖家已经编辑了商品属性,但是需要过一段时间才能被买家看到。在互联网应用中,这种延迟通常是可以接受的,但是具体应用仍需慎重对待。还有一种策略是数据更新时立即更新缓存,不过这也会带来更多系统开销和事务一致性的问题。

    4.缓存可用性

    通过分布式缓存服务器集群,将缓存数据分布到集群多台服务器上可在一定程度上改善缓存的可用性。当一台缓存服务器宕机的时候,只有部分缓存数据丢失,重新从数据库加载这部分数据不会对数据库产生很大影响。

    5.缓存预热

    缓存中存放的是热点数据,热点数据又是缓存系统利用LRU(最近最久未用算法)对不断访问的数据筛选淘汰出来的,这个过程需要花费较长的时间。新启动的缓存系统如果没有任何数据,在重建缓存数据的过程中,系统的性能和数据库负载都不太好,那么最好在缓存系统启动时就把热点数据加载好,这个缓存预加载手段叫作缓存预热(warm up)。对于一些元数据如城市地名列表、类目信息,可以在启动时加载数据库中全部数据到缓存进行预热

    6.缓存穿透

    如果因为不恰当的业务、或者恶意攻击持续高并发地请求某个不存在的数据,由于缓存没有保存该数据,所有的请求都会落到数据库上,会对数据库造成很大压力,甚至崩溃。一个简单的对策是将不存在的数据也缓存起来(其value值为null)

    分布式缓存架构

    分布式缓存指缓存部署在多个服务器组成的集群中,以集群方式提供缓存服务,其架构方式有两种,一种是以JBoss C ache为代表的需要更新同步的分布式缓存一种是以Memcached为代表的不互相通信的分布式缓存

    Memcached

    2.异步操作

    需要注意的是,由于数据写入消息队列后立即返回给用户,数据在后续的业务校验、写数据库等操作可能失败,因此在使用消息队列进行业务异步处理后,需要适当修改业务流程进行配合,如订单提交后,订单数据写入消息队列,不能立即返回用户订单提交成功,需要在消息队列的订单消费者进程真正处理完该订单,甚至商品出库后,再通过电子邮件或SM S消息通知用户订单成功,以免交易纠纷。

    任何可以晚点做的事情都应该晚点再做。保证数据的正确性

    3.使用集群

    4.代码优化

    1.多线程

    从资源利用的角度看,使用多线程的原因主要有两个:IO阻塞与多CPU

    网站的应用程序一般都被Web服务器容器管理,用户请求的多线程也通常被Web服务器容器管理,但不管是Web容器管理的线程,还是应用程序自己创建的线程,一台服务器上启动多少线程合适呢?

    假设服务器上执行的都是相同类型任务,针对该类任务启动的线程数有个简化的估算公式可供参考:

    启动线程数=[任务执行时间/(任务执行时间×IO等待时间)]×CPU内核数

    最佳启动线程数和CPU内核数量成正比,和IO阻塞时间成反比。如果任务都是CPU计算型任务,那么线程数最多不超过CPU内核数,因为启动再多线程,CPU也来不及调度相反如果是任务需要等待磁盘操作,网络响应,那么多启动线程有助于提高任务并发度,提高系统吞吐能力,改善系统性能。(看是CPU计算型还是磁盘操作!)

    多线程需要注意线程安全的问题,这也是缺乏经验的网站工程师最容易犯错的地方,而线程安全B ug又难以测试和重现,网站故障中,许多所谓偶然发生的“灵异事件”都和多线程并发问题有关。对网站而言,不管有没有进行多线程编程,工程师写的每一行代码都会被多线程执行,因为用户请求是并发提交的,也就是说,所有的资源——对象、内存、文件、数据库,乃至另一个线程都可能被多线程并发访问。

    2.资源复用

    系统运行时,要尽量减少那些开销很大的系统资源的创建和销毁,比如数据库连接、网络通信连接、线程、复杂对象等。从编程角度,资源复用主要有两种模式:单例(Singleton)对象池(Object Pool)

    单例虽然是GoF经典设计模式中较多被诟病的一个模式,但由于目前Web开发中主要使用贫血模式,从Service到D ao都是些无状态对象,无需重复创建,使用单例模式也就自然而然了。事实上,Java开发常用的对象容器Spring默认构造的对象都是单例(需要注意的是Spring的单例是Spring容器管理的单例,而不是用单例模式构造的单例)。

    前面说过,对于每个Web请求(HTTP Request), Web应用服务器都需要创建一个独立的线程去处理,这方面,应用服务器也采用线程池(Thread Pool)的方式。这些所谓的连接池、线程池,本质上都是对象池,即连接、线程都是对象,池管理方式也基本相同

    4.4存储性能优化

    1.机械硬盘VS固态硬盘

    机械硬盘是目前最常用的一种硬盘,通过马达驱动磁头臂,带动磁头到指定的磁盘位置访问数据,由于每次访问数据都需要移动磁头臂,因此机械硬盘在数据连续访问(要访问的数据存储在连续的磁盘空间上)和随机访问(要访问的数据存储在不连续的磁盘空间)时,由于移动磁头臂的次数相差巨大,性能表现差别也非常大

    2.B+树.VS.LSM树

    本书前面提到,由于传统的机械磁盘具有快速顺序读写、慢速随机读写的访问特性,这个特性对磁盘存储结构和算法的选择影响甚大。

    通常会对数据排序后存储,加快数据检索速度,这就需要保证数据在不断更新、插入、删除后依然有序,传统关系数据库的做法是使用B+树

    目前许多NoSQL产品采用LSM树作为主要数据结构。

    3.RAID.VS.HDFS

    RAID技术可以通过硬件实现,比如专用的RAID卡或者主板直接支持,也可以通过软件实现。RAID技术在传统关系数据库及文件系统中应用比较广泛,但是在大型网站比较喜欢使用的NoSQL,以及分布式文件系统中,RAID技术却遭到冷落。

    现在一般用HDFS,HDFS配合M apR educe等并行计算框架进行大数据处理时,可以在整个集群上并发读写访问所有的磁盘,无需RAID支持。

    5.万无一失:网站的高可用架构

    5.1网站可用性的度量与考核

    网站的页面能完整呈现在最终用户面前,需要经过很多个环节,任何一个环节出了问题,都可能导致网站页面不可访问。DNS会被劫持、CDN服务可能会挂掉、网站服务器可能会宕机、网络交换机可能会失效、硬盘会损坏、网卡会松掉、甚至机房会停电、空调会失灵、程序会有B ug、黑客会攻击、促销会引来大量访问、第三方合作伙伴的服务会不可用……要保证一个网站永远完全可用几乎是一件不可能完成的使命。

    一个典型的网站设计通常遵循如图所示的基本分层架构模型。

    典型的分层模型是三层,即应用层、服务层、数据层;各层之间具有相对独立性,应用层主要负责具体业务逻辑处理服务层负责提供可复用的服务数据层负责数据的存储与访问。中小型网站在具体部署时,通常将应用层和服务层部署在一起,而数据层则另外部署,如图5.3所示(事实上,这也是网站架构演化的第一步)。

    在复杂的大型网站架构中,划分的粒度会更小,更详细,结构更加复杂,但通常还是可以将服务器划分到这三层中。

    应用层

    位于应用层的服务器通常为了应对高并发的访问请求,会通过负载均衡设备将一组服务器组成一个集群共同对外提供服务,当负载均衡设备通过心跳检测等手段监控到某台应用服务器不可用时,就将其从集群列表中剔除,并将请求分发到集群中其他可用的服务器上,使整个集群保持可用,从而实现应用高可用。

    服务层

    位于服务层的服务器情况和应用层的服务器类似,也是通过集群方式实现高可用,只是这些服务器被应用层通过分布式服务调用框架访问,分布式服务调用框架会在应用层客户端程序中实现软件负载均衡,并通过服务注册中心对提供服务的服务器进行心跳检测,发现有服务不可用,立即通知客户端程序修改服务访问列表,剔除不可用的服务器。

    数据层

    位于数据层的服务器情况比较特殊,数据服务器上存储着数据,为了保证服务器宕机时数据不丢失,数据访问服务不中断,需要在数据写入时进行数据同步复制,将数据写入多台服务器上,实现数据冗余备份。当数据服务器宕机时,应用程序将访问切换到有备份数据的服务器上。

    5.3高可用的应用

    应用层主要处理网站应用的业务逻辑,因此有时也称作业务逻辑层,应用的一个显著特点是应用的无状态性

    所谓无状态的应用是指应用服务器不保存业务的上下文信息,而仅根据每次请求提交的数据进行相应的业务逻辑处理,多个服务实例(服务器)之间完全对等,请求提交到任意服务器,处理结果都是完全一样的

    1.通过负载均衡进行无状态服务的失效转移

    2.应用服务器集群的Session管理

    应用服务器的高可用架构设计主要基于服务无状态这一特性,但是事实上,业务总是有状态的,在交易类的电子商务网站,需要有购物车记录用户的购买信息,用户每次购买请求都是向购物车中增加商品;在社交类的网站中,需要记录用户的当前登录状态、最新发布的消息及好友状态等,用户每次刷新页面都需要更新这些信息。

    Web应用中将这些多次请求修改使用的上下文对象称作会话(Session),单机情况下,Session可由部署在服务器上的Web容器(如JBoss)管理。在使用负载均衡的集群环境中,由于负载均衡服务器可能会将请求分发到集群任何一台应用服务器上,所以保证每次请求依然能够获得正确的Session比单机时要复杂很多

    集群环境下,Session管理主要有以下几种手段。

    1.Session复制

    原理很简单,在集群中的几台服务器之间同步Session对象,使得每台服务器上都保存有用户的Session信息,这样任何一台服务器宕机,都可以在其他服务器上找到Session。

    缺点是,大量用户访问的情况下,会出现服务器内存不够Session使用的情况。

    而大型网站的核心应用集群就是数千台服务器,同时在线用户可达千万,因此并不适用这种方案。

    2.Session绑定

    Session绑定可以利用负载均衡的源地址Hash算法实现,负载均衡服务器总是将来自同一IP的请求分发到同一台服务器上,这种方法又被称作为会话粘滞

    但Session绑定的方案不符合我们的要求,如果一台服务器宕机,那么该服务器上的Session将不存在,用户请求切换后无法完成业务。

    因此虽然大部分负载均衡服务器都提供源地址负载均衡算法,但很少有网站利用这个算法进行Session管理。

    3.利用Cookie记录Session

    利用Cookie记录Session也有缺点,比如受Cookie大小限制,能记录的信息有限,每次请求响应都需要传输Cookie,影响性能;如果用户关闭C ookie,访问就会不正常。但是由于C ookie的简单易用,可用性高,支持应用服务器的线性伸缩,而大部分应用需要记录的Session信息又比较小。因此事实上,许多网站都或多或少地使用C ookie记录Session

    4.Session服务器

    那么有没有可用性高、伸缩性好、性能也不错,对信息大小又没有限制的服务器集群Session管理方案呢?

    答案就是Session服务器。利用独立部署的Session服务器(集群)统一管理S ession,应用服务器每次读写Session时,都访问Session服务器,如图所示。

    这种解决方案事实上是将应用服务器的状态分离分为无状态的应用服务器和有状态的Session服务器,然后针对这两种服务器的不同特性分别设计其架构。

    对于有状态的Session服务器,一种比较简单的方法是利用分布式缓存、数据库等,在这些产品的基础上进行包装,使其符合Session的存储和访问要求。如果业务场景对Session管理有比较高的要求,比如利用Session服务集成单点登录(SSO)、用户服务等功能,则需要开发专门的Session服务管理平台。

    5.4高可用的服务

    5.5高可用的数据

    保证数据存储高可用的手段主要是1.数据备份和2.失效转移机制。数据备份是保证数据有多个副本,任意副本的失效都不会导致数据的永久丢失,从而实现数据完全的持久化。而失效转移机制则保证当一个数据副本不可访问时,可以快速切换访问数据的其他副本,保证系统可用。

    关于缓存服务的高可用,在实践中争议很大,一种观点认为缓存已经成为网站数据服务的重要组成部分,事实上承担了业务中绝大多数的数据读取访问服务,缓存服务失效可能会导致数据库负载过高而宕机,进而影响整个网站的可用性,因此缓存服务需要实现和数据存储服务同样的高可用。

    另一种观点认为,缓存服务不是数据存储服务,缓存服务器宕机引起缓存数据丢失导致服务器负载压力过高应该通过其他手段解决,而不是提高缓存服务本身的高可用。

    笔者持后一种观点,对于缓存服务器集群中的单机宕机,如果缓存服务器集群规模较大,那么单机宕机引起的缓存数据丢失比例和数据库负载压力变化都较小,对整个系统影响也较小。扩大缓存服务器集群规模的一个简单手段就是整个网站共享同一个分布式缓存集群,单独的应用和产品不需要部署自己的缓存服务器,只需要向共享缓存集群申请缓存资源即可。并且通过逻辑或物理分区的方式将每个应用的缓存部署在多台服务器上,任何一台服务器宕机引起的缓存失效都只影响应用缓存数据的一小部分,不会对应用性能和数据库负载造成太大影响。

    C AP原理

    在讨论高可用数据服务架构之前,必须先讨论的一个话题是,为了保证数据的高可用,网站通常会牺牲另一个也很重要的指标:数据一致性。也就是说,数据的高可用性跟数据的一致性不可兼得。

    高可用的数据有如下几个层面的含义。

    1.数据持久性

    2.数据的可访问性

    3.数据一致性

    CAP原理认为,一个提供数据服务的存储系统无法同时满足数据一致性(C onsistency)、数据可用性(A vailib ility)、分区耐受性(Patition Tolerance,系统具有跨网络分区的伸缩性)这三个条件,如图。

    在大型网站中,通常会选择强化分布式存储系统的可用性(A)和伸缩性(P),而在某种程度上放弃一致性(C)。

    数据一致性可以分为如下几点:

    1.数据强一致

    各个副本的数据在物理存储中总是一致的,数据更新操作结果和操作响应总是一致的,即操作响应通知更新失败,那么数据一定没有被更新,而不是处于不确定状态。

    2.数据用户一致

    数据在物理存储中的各个副本的数据可能是不一致的,但是终端用户访问时,通过纠错和校验机制,可以确定一个一致的且正确的数据返回给用户。

    3.数据最终一致

    这是数据一致性中较弱的一种,即物理存储的数据可能是不一致的,终端用户访问到的数据可能也是不一致的(同一用户连续访问,结果不同;或者不同用户同时访问,结果不同),但系统经过一段时间(通常是一个比较短的时间段)的自我恢复和修正,数据最终会达到一致

    关系数据库热备机制就是通常所说的M aster-S lave同步机制。M aster-S lave机制不但解决了数据备份问题,还改善了数据库系统的性能,实践中,通常使用读写分离的方法访问S lave和M aster数据库,写操作只访问M aster数据库,读操作只访问S lave数据库

    关于数据的失效转移:

    失效转移操作主要由三部分组成:1.失效确认,2.失效转移,3.数据恢复

    1.失效确认

    判断服务器宕机是系统进行失效转移的第一步,系统确认一台服务器是否宕机的手段有两种:1.心跳检测2.应用程序访问失败报告,如图。

    2.访问转移

    3.数据恢复

    网站发布的流程:

    网站发布毕竟是一次提前预知的服务器宕机,所以过程可以更柔和,对用户影响更小。通常使用发布脚本来完成发布,其流程如图。

    目前大部分网站都采用Web自动化测试技术,使用自动测试工具或脚本完成测试。比较流行的Web自动化测试工具是ThoughtW orks开发的SeleniumSelenium运行在浏览器中,模拟用户操作进行测试,因此Selenium可以同时完成Web功能测试和浏览器兼容测试

    在网站发布时,并不是把测试通过的代码包直接发布到线上服务器,而是先发布到预发布机器上,开发工程师和测试工程师在预发布服务器上进行预发布验证,执行一些典型的业务流程,确认系统没有问题后才正式发布。

    5.7网站运行监控

    6.永无止境:网站的伸缩性架构

    所谓网站的伸缩性是指不需要改变网站的软硬件设计,仅仅通过改变部署服务器数量就可以扩大或者缩小网站的服务处理能力。

    回顾网站架构发展历程, 网站架构发展史就是一部不断向网站添加服务器的历史。只要工程师能向网站的服务器集群中添加新的机器,只要新添加的服务器能线性提高网站的整体服务处理能力,网站就无需为不断增长的用户和访问而焦虑。

    6.2应用服务器集群的伸缩性设计

    实现负载均衡的主要算法

    1.HTTP重定向负载均衡

    这种负载均衡方案的优点是比较简单缺点是浏览器需要两次请求服务器才能完成一次访问,性能较差;重定向服务器自身的处理能力有可能成为瓶颈,整个集群的伸缩性规模有限;使用HTTP302响应码重定向,有可能使搜索引擎判断为SEO作弊,降低搜索排名。因此实践中使用这种方案进行负载均衡的案例并不多见

    2.DNS域名解析负载均衡

    在DNS服务器中配置多个A记录,如:www.m ysite.com IN A 114.100.80.1、www.m ysite.com IN A 114.100.80.2、www.m ysite.com IN A 114.100.80.3。
    每次域名解析请求都会根据负载均衡算法计算一个不同的IP地址返回,这样A记录中配置的多个服务器就构成一个集群,并可以实现负载均衡。

    DNS域名解析负载均衡的优点是将负载均衡的工作转交给DNS,省掉了网站管理维护负载均衡服务器的麻烦,同时许多DNS还支持基于地理位置的域名解析,即会将域名解析成距离用户地理最近的一个服务器地址,这样可加快用户访问速度,改善性能。但是DNS域名解析负载均衡也有缺点,就是1.目前的DNS是多级解析,每一级DNS都可能缓存A记录,当下线某台服务器后,即使修改了DNS的A记录,要使其生效也需要较长时间,这段时间,DNS依然会将域名解析到已经下线的服务器,导致用户访问失败;而且2.DNS负载均衡的控制权在域名服务商那里,网站无法对其做更多改善和更强大的管理。

    事实上,大型网站总是部分使用DNS域名解析,利用域名解析作为第一级负载均衡手段,即域名解析得到的一组服务器并不是实际提供Web服务的物理服务器,而是同样提供负载均衡服务的内部服务器,这组内部负载均衡服务器再进行负载均衡,将请求分发到真实的Web服务器上

    大型网站利用DNS域名解析作为第一级的负载均衡手段。

    3.反向代理负载均衡

    前面我们提到利用反向代理缓存资源,以改善网站性能。实际上,在部署位置上,反向代理服务器处于Web服务器前面(这样才可能缓存Web响应,加速访问),这个位置也正好是负载均衡服务器的位置,所以大多数反向代理服务器同时提供负载均衡的功能,管理一组Web服务器,将请求根据负载均衡算法转发到不同Web服务器上。Web服务器处理完成的响应也需要通过反向代理服务器返回给用户。由于Web服务器不直接对外提供访问,因此Web服务器不需要使用外部IP地址,而反向代理服务器则需要配置双网卡和内部外部两套IP地址

    由于反向代理服务器转发请求在HTTP协议层面,因此也叫应用层负载均衡其优点是和反向代理服务器功能集成在一起,部署简单缺点是反向代理服务器是所有请求和响应的中转站,其性能可能会成为瓶颈

    4.IP负载均衡

    在网络层通过修改目标地址进行负载均衡。

    5.数据链路层负载均衡

    顾名思义,数据链路层负载均衡是指在通信协议的数据链路层修改mac地址进行负载均衡。

    这种数据传输方式又称作三角传输模式负载均衡数据分发过程中不修改IP地址,只修改目的m ac地址,通过配置真实物理服务器集群所有机器虚拟IP和负载均衡服务器IP地址一致,从而达到不修改数据包的源地址和目的地址就可以进行数据分发的目的,由于实际处理请求的真实物理服务器IP和数据请求目的IP一致,不需要通过负载均衡服务器进行地址转换,可将响应数据包直接返回给用户浏览器,避免负载均衡服务器网卡带宽成为瓶颈。这种负载均衡方式又称作直接路由方式(DR)。

    使用三角传输模式的链路层负载均衡是目前大型网站使用最广的一种负载均衡手段。在Linux平台上最好的链路层负载均衡开源产品是LVS(Linux V irtual Server)。

    6.负载均衡算法

    负载均衡服务器的实现分成两个部分:

    1.根据负载均衡算法和Web服务器列表计算得到集群中一台Web服务器的地址。
    2.将请求数据发送到该地址对应的Web服务器上。

    前面描述了如何将请求数据发送到Web服务器上,而具体的负载均衡算法通常有如下几种:

    1.轮询(RR)
    2.加权轮询(WRR)
    3.随机(Random)

    4.最少连接(Least Connections)
    记录每个应用服务器正在处理的连接数(请求数),将新到的请求分发到最少连接的服务器上,应该说,这是最符合负载均衡定义的算法。同样,最小连接算法也可以实现加权最少连接。

    5.源地址散列(Source Hashing)

    6.3分布式缓存集群的伸缩性设计

    我们在本书第4章讨论过分布式缓存,不同于应用服务器集群的伸缩性设计,分布式缓存集群的伸缩性不能使用简单的负载均衡手段来实现。

    必须让新上线的缓存服务器对整个分布式缓存集群影响最小,也就是说新加入缓存服务器后应使整个缓存服务器集群中已经缓存的数据尽可能还被访问到,这是分布式缓存集群伸缩性设计的最主要目标。

    1.Memcached分布式缓存集群的访问模型

    如果使用朴素的Hash路由算法,将会出现问题。本来加入新的缓存服务器是为了降低数据库的负载压力,但是操作不当却导致了数据库的崩溃。如果不对问题和解决方案有透彻了解,网站技术总有想不到的陷阱让架构师一脚踩空。遇到这种情况,用某网站一位资深架构师的话说,就是“一股寒气从脚底板窜到了脑门心”。

    能不能通过改进路由算法,使得新加入的服务器不影响大部分缓存数据的正确命中呢?目前比较流行的算法是一致性Hash算法

    一致性Hash算法也有小问题。

    计算机领域有句话:计算机的任何问题都可以通过增加一个虚拟层来解决。计算机硬件、计算机网络、计算机软件都莫不如此。计算机网络的7层协议,每一层都可以看作是下一层的虚拟层;计算机操作系统可以看作是计算机硬件的虚拟层;Java虚拟机可以看作是操作系统的虚拟层;分层的计算机软件架构事实上也是利用虚拟层的概念。

    解决上述一致性Hash算法带来的负载不均衡问题,也可以通过使用虚拟层的手段:将每台物理缓存服务器虚拟为一组虚拟缓存服务器,将虚拟服务器的Hash值放置在Hash环上,KEY在环上先找到虚拟服务器节点,再得到物理服务器的信息。

    6.4数据存储服务器集群的伸缩性设计

    1.关系性数据库集群的伸缩性设计

    目前网站在线业务应用中比较成熟的支持数据分片的分布式关系数据库产品主要有Cobar。其架构图如下。

    Cobar系统组件模型如图。

    前端通信模块负责和应用程序通信,接收到SQL请求(select * from users where userid in (12,22,23))后转交给SQL解析模块,SQL解析模块解析获得SQL中的路由规则查询条件(userid in(12,22,23))再转交给SQL路由模块,SQL路由模块根据路由规则配置(userid为偶数路由至数据库A, userid为奇数路由至数据库B)将应用程序提交的SQL分解成两条SQ L(select * from users w here userid in (12,22);select * from users w here userid in (23);)转交给SQL执行代理模块,发送至数据库A和数据库B分别执行。

    数据库A和数据库B的执行结果返回至SQL执行模块,通过结果合并模块将两个返回结果集合并成一个结果集,最终返回给应用程序,完成在分布式数据库中的一次访问请求。

    那么Cobar如何做集群的伸缩呢?
    Cobar的伸缩有两种:1.Cobar服务器集群的伸缩2.MySQL服务器集群的伸缩

    2.NoSQL数据库的伸缩性设计

    大型网站遇到了关系数据库难以克服的缺陷——糟糕的海量数据处理能力及僵硬的设计约束,局面才有所改善。为了解决上述问题,NoSQL这一概念被提了出来,以弥补关系数据库的不足。

    NoSQL,主要指非关系的、分布式的数据库设计模式。也有许多专家将NoSQL解读为N ot O nly SQ L,表示NoSQL只是关系数据库的补充,而不是替代方案。一般而言,NoSQL数据库产品都放弃了关系数据库的两大重要基础:以关系代数为基础的结构化查询语言(SQL)和事务一致性保证(ACID)。而强化其他一些大型网站更关注的特性:高可用性和可伸缩性

    开源社区有各种N oSQL产品,其支持的数据结构和伸缩特性也各不相同,目前看来,应用最广泛的是Apache HBase

    6.5小结

    高手定律

    这个世界只有遇不到的问题,没有解决不了的问题,高手之所以成为高手,是因为他们遇到了常人很难遇到的问题,并解决了。所以百度有很多广告搜索的高手,淘宝有很多海量数据的高手,Q Q有很多高并发业务的高手,原因大抵如此。一个100万用户的网站,不会遇到1亿用户同时在线的问题;一个拥有100万件商品网站的工程师,可能无法理解一个拥有10亿件商品网站的架构。

    救世主定律

    遇到问题,分析问题,最后总能解决问题。如果遇到问题就急匆匆地从外面挖一个高手,然后指望高手如探囊取物般轻松搞定,最后怕是只有彼此抱怨和伤害。许多问题只是看起来一样,具体问题总是要具体对待的,没有银弹,没有救世主。所以这个定律准确地说应该是“没有救世主定律”。

    7.按需应变:网站的可扩展架构

    网站扩展性架构设计:对现有系统影响最小的情况下,系统功能可持续扩展及提升的能力。

    首先厘清容易混淆的两个概念:

    1.扩展性(Extensibility):

    指对现有系统影响最小的情况下,系统功能可持续扩展或提升的能力。表现在系统基础设施稳定不需要经常变更,应用之间较少依赖和耦合,对需求变更可以敏捷响应。它是系统架构设计层面的开闭原则(对扩展开放,对修改关闭),架构设计考虑未来功能扩展,当系统增加新功能时,不需要对现有系统的结构和代码进行修改。

    2.伸缩性(Scalability):

    指系统能够通过增加(减少)自身资源规模的方式增强(减少)自己计算处理事务的能力。如果这种增减是成比例的,就被称作线性伸缩性。在网站架构中,通常指利用集群的方式增加服务器数量、提高系统的整体事务吞吐能力。

    7.2利用分布式消息队列降低系统耦合性

    如果模块之间不存在直接调用,那么新增模块或者修改模块就对其他模块影响最小,这样系统的可扩展性无疑更好一些。

    1.事件驱动架构

    事件驱动架构(Event Driven Architecture):通过在低耦合的模块之间传输事件消息,以保持模块的松散耦合,并借助事件消息的通信完成模块间合作,典型的EDA架构就是操作系统中常见的生产者消费者模式。在大型网站架构中,具体实现手段有很多,最常用的是分布式消息队列,如图所示。

    2.分布式消息队列

    目前开源的和商业的分布式消息队列产品有很多,比较著名的如Apache ActiveMQ等,这些产品除了实现分布式消息队列的一般功能,在可用性、伸缩性、数据一致性、性能和可管理性方面也做了很多改善。

    7.3利用分布式服务打造可复用的业务平台

    巨无霸的应用系统会带来很多问题:
    1.编译,部署困难
    2.代码分支管理困难
    3.数据库连接耗尽
    4.新增业务困难

    解决方案就是拆分,将模块独立部署,降低系统耦合性。拆分可以分为纵向拆分和横向拆分两种。

    纵向拆分:将一个大应用拆分为多个小应用,如果新增业务较为独立,那么就直接将其设计部署为一个独立的Web应用系统。

    横向拆分:将复用的业务拆分出来,独立部署为分布式服务,新增业务只需要调用这些分布式服务,不需要依赖具体的模块代码,即可快速搭建一个应用系统,而模块内业务逻辑变化的时候,只要接口保持一致就不会影响业务程序和其他模块。

    1.Web Service与企业级分布式服务

    2.大型网站分布式服务的需求和特点

    对于大型网站,除了Web Services所提供的服务注册与发现,服务调用等标准功能,还需要分布式服务框架能够支持如下功能。

    1.负载均衡
    2.失效转移
    3.高效的远程通信
    4.整合异构系统
    5.对应用最少侵入
    6.版本管理
    7.实时监控

    3.分布式服务框架设计

    例如Facebook的Thrift。

    服务消费者程序通过服务接口使用服务,而服务接口通过代理加载具体服务,具体服务可以是本地的代码模块,也可以是远程的服务,因此对应用较少侵入:应用程序只需要调用服务接口,服务框架根据配置自动调用本地或远程实现。

    服务框架客户端模块通过服务注册中心加载服务提供者列表(服务提供者启动后自动向服务注册中心注册自己可提供的服务接口列表),查找需要的服务接口,并根据配置的负载均衡策略将服务调用请求发送到某台服务提供者服务器。如果服务调用失败,客户端模块会自动从服务提供者列表选择一个可提供同样服务的另一台服务器重新请求服务,实现服务的自动失效转移,保证服务高可用。

    7.4可扩展的数据结构

    开放平台是网站内部和外部交互的接口,外部需要面对众多的第三方开发者,内部需要面对网站内诸多的业务服务。虽然每个网站的业务场景和需求都各不相同,但是开放平台的架构设计却大同小异,如图所示。

    API接口:是开放平台暴露给开发者使用的一组API,其形式可以是RESTful、WebService、RPC等各种形式。
    协议转换:将各种API输入转换成内部服务可以识别的形式,并将内部服务的返回封装成API的格式。
    安全:除了一般应用需要的身份识别、权限控制等安全手段,开放平台还需要分级的访问带宽限制,保证平台资源被第三方应用公平合理使用,也保护网站内部服务不会被外部应用拖垮。
    审计:记录第三方应用的访问情况,并进行监控、计费等。
    路由:将开放平台的各种访问路由映射到具体的内部服务。
    流程:将一组离散的服务组织成一个上下文相关的新服务,隐藏服务细节,提供统一接口供开发者调用。

    7.6小结

    既然我们知道网站不停上新产品是其生存的本能,谁能更快更好地推出更多的新产品,谁就活得更滋润,那么工程师就要做好准备应付这种局面。马克思的劳动价值理论告诉我们,产品的内在价值在于劳动的时间,劳动的时间不在于个体付出的劳动时间,而在于行业一般劳动时间,资本家只会为行业一般劳动时间买单,如果你的效率低于行业一般劳动时间,对不起,请你自愿加班。反之,如果你有一个更具有扩展性的网站架构,可以更快速地开发新产品,也许你也享受不了只上半天班的福利,但是至少在这个全行业加班的互联网领域,你能够按时下班,陪陪家人,看看星星。

    第三篇:案例

    10.1Wikipedia网站整体架构

    架构如图。

    Wikipedia架构的主要组成部分如下。
    GeoDNS:基于开源域名服务器软件BIND(Berkeley Internet Name Domain)的增强版本,可将域名解析到离用户最近的服务器。
    LVS:基于Linux的开源负载均衡服务器。
    Squid:基于Linux的开源反向代理服务器。
    Lighttpd:开源的应用服务器,较主流的Apache服务器更轻量、更快速。实践中,有许多网站使用L ighttpd作为图片服务器。
    PHP:免费的Web应用程序开发语言,最流行的网站建站语言。
    Memcached:无中心高性能的开源分布式缓存系统,稳定、可靠、历久弥新,是网站分布式缓存服务必备的。
    Lucene:由Apache出品,Java开发的开源全文搜索引擎。
    MySQL:开源的关系数据库管理系统,虽被Oracle收购,但开源社区将其继续开源发展的决心不动摇。

    关于故障

    在讨论解决方案之前,我们先对故障进行分类,针对不同故障情况分别对待。对于一个分布式存储系统而言,影响系统整体可用性的故障可以分成以下三类。

    × 瞬时故障:引起这类故障的主要原因是网络通信瞬时中断、服务器内存垃圾回收或后台线程繁忙停止数据访问操作响应。其特点是故障时间短,在秒级甚至毫秒级系统即可自行恢复正常响应。

    × 临时故障:引起这类故障的主要原因是交换机宕机、网卡松动等导致的网络通信中断;系统升级、停机维护等一般运维活动引起的服务关闭;内存损坏、CPU过热等硬件原因导致的服务器宕机;这类故障的主要特点是需要人工干预(更换硬件、重启机器等)才能恢复正常。通常持续时间需要几十分钟甚至几小时。故障时间可分为两个阶段:临时故障期间,临时故障恢复期间。

    × 永久故障:引起这类故障的主要原因只有一个:硬盘损坏,数据丢失。虽然损坏硬盘和损坏内存一样,可以通过更换硬盘来重新启动机器,但是丢失的数据却永远找不回来了,因此其处理策略也和前面两种故障完全不同,恢复系统到正常状态也需要更长的时间。故障时间可分为两个阶段:永久故障期间和永久故障恢复期间。

    12.1秒杀活动的技术挑战

    1.对现有网站业务造成冲击
    2.高并发下的应用,数据库负载
    3.突然增加的网络及服务器带宽
    4.直接下单

    12.2秒杀系统的应对策略

    1.秒杀系统独立部署
    2.秒杀商品页面静态化
    3.租借秒杀活动网络带宽
    4.动态生成随机下单页面URL

    13.3高并发情况下锁引发的故障

    故障现象:某应用服务器不定时地因为响应超时而报警,但是很快又超时解除,恢复正常,如此反复,让运维人员非常苦恼。

    原因分析:程序中某个单例对象(singleton object)中多处使用了synchronized(this),由于this对象只有一个,所有的并发请求都要排队获得这唯一的一把锁。一般情况下,都是一些简单操作,获得锁,迅速完成操作,释放锁,不会引起线程排队。但是某个需要远程调用的操作也被加了synchronized(this),这个操作只是偶尔会被执行,但是每次执行都需要较长的时间才能完成,这段时间锁被占用,所有的用户线程都要等待,响应超时,这个操作执行完后释放锁,其他线程迅速执行,超时解除。

    经验教训:
    × 使用锁操作要谨慎。

    第四篇:架构师

    展开全文
  • DDD(领域驱动设计)

    万次阅读 多人点赞 2019-07-08 15:25:45
     领域驱动设计(简称 ddd)概念来源于2004年著名建模专家eric evans发表的他最具影响力的书籍:《domain-driven design –tackling complexity in the heart of software》(中文译名:领域驱动设计—软件核心复杂性...

    基本概念:

      领域驱动设计(简称 ddd)概念来源于2004年著名建模专家eric evans发表的他最具影响力的书籍:《domain-driven design –tackling complexity in the heart of software》(中文译名:领域驱动设计—软件核心复杂性应对之道)一书。,书中提出了“领域驱动设计(简称 ddd)”的概念。

             领域驱动设计一般分为两个阶段:

            1.   以一种领域专家、设计人员、开发人员都能理解的“通用语言”作为相互交流的工具,在不断交流的过程中发现和挖出一些主要的领域概念,然后将这些概念设计成一个领域模型;

             2.   由领域模型驱动软件设计,用代码来表现该领域模型。领域需求的最初细节,在功能层面通过领域专家的讨论得出。

           领域驱动设计告诉我们,在通过软件实现一个业务系统时,建立一个领域模型是非常重要和必要的,因为领域模型具有以下特点:

         1.   领域模型是对具有某个边界的领域的一个抽象,反映了领域内用户业务需求的本质;领域模型是有边界的,只反应了我们在领域内所关注的部分;

         2.   领域模型只反映业务,和任何技术实现无关;领域模型不仅能反映领域中的一些实体概念,如货物,书本,应聘记录,地址,等;还能反映领域中的一些过程概念,如资金转账,等;

         3.   领域模型确保了我们的软件的业务逻辑都在一个模型中,都在一个地方;这样对提高软件的可维护性,业务可理解性以及可重用性方面都有很好的帮助;

         4.   领域模型能够帮助开发人员相对平滑地将领域知识转化为软件构造;

         5.  领域模型贯穿软件分析、设计,以及开发的整个过程;领域专家、设计人员、开发人员通过领域模型进行交流,彼此共享知识与信息;因为大家面向的都是同一个模型,所以可以防止需求走样,可以让软件设计开发人员做出来的软件真正满足需求;

         6.  要建立正确的领域模型并不简单,需要领域专家、设计、开发人员积极沟通共同努力,然后才能使大家对领域的认识不断深入,从而不断细化和完善领域模型;

         7.  为了让领域模型看的见,我们需要用一些方法来表示它;图是表达领域模型最常用的方式,但不是唯一的表达方式,代码或文字描述也能表达领域模型;

         8.  领域模型是整个软件的核心,是软件中最有价值和最具竞争力的部分;设计足够精良且符合业务需求的领域模型能够更快速的响应需求变化;

    领域驱动设计中的一些基本概念:

    1.实体(entity):

            根据eric evans的定义,”一个由它的标识定义的对象叫做实体”。通常实体具备唯一id,能够被持久化,具有业务逻辑,对应现实世界业务对象。

             实体一般和主要的业务/领域对象有一个直接的关系。一个实体的基本概念是一个持续抽象的生命,可以变化不同的状态和情形,但总是有相同的标识。

    需要注意的是:

             一些开发人员将实体当成了orm意义上的实体,而不是业务所有和业务定义的领域对象。在一些实现中采用了transaction script风格的架构,使用贫血的领域模型。这种认识上的混乱,在领域驱动架构中,不愿意在领域对象中加入业务逻辑而导致贫血的领域模型,同时还可能使混乱的服务对象激增。

    2.值对象(value object)

            值对象的定义是:描述事物的对象;更准确的说,一个没有概念上标识符描述一个领域方面的对象。这些对象是用来表示临时的事物,或者可以认为值对象是实体的属性,这些属性没有特性标识但同时表达了领域中某类含义的概念。

            通常值对象不具有唯一id,由对象的属性描述,可以用来传递参数或对实体进行补充描述。

            作为实体属性的描述时,值对象也会被存储。在uml的类图上显现为一对多或一对一的关系。在orm映射关系上需要采用较复杂的一对多或一对一关系映射。

            关于实体与值对象的一个例子:比如员工信息的属性,如住址,电话号码都可以改变;然而,同一个员工的实体的标识将保持不变。因此,一个实体的基本概念是一个持续抽象的生命,可以变化不同的状态和情形,但总是有相同的标识。

    实体与值对象的区别

             实体具有唯一标识,而值对象没有唯一标识,这是实体和值对象间的最大不同。

            实体就是领域中需要唯一标识的领域概念。有两个实体,如果唯一标识不一样,那么即便实体的其他所有属性都一样,也认为是两个不同的实体;一个实体的基本概念是一个持续抽象的生命,可以变化不同的状态和情形,但总是有相同的标识。

            不应该给实体定义太多的属性或行为,而应该寻找关联,发现其他一些实体或值对象,将属性或行为转移到其他关联的实体或值对象上。

            如果两个对象的所有的属性的值都相同,我们会认为它们是同一个对象的话,那么我们就可以把这种对象设计为值对象。值对象在判断是否是同一个对象时是通过它们的所有属性是否相同,如果相同则认为是同一个值对象;而实体是否为同一个实体的区分,只是看实体的唯一标识是否相同,而不管实体的属性是否相同。

            值对象另外一个明显的特征是不可变,即所有属性都是只读的。因为属性是只读的,所以可以被安全的共享;当共享值对象时,一般有复制和共享两种做法,具体采用哪种做法还要根据实际情况而定。

            箴言:如果值对象时可共享的,它们应该是不可变的。(值对象应该保持尽量的简单)

             值对象的设计应尽量简单,不要让它引用很多其他的对象,因为本质上讲值对象只是代表一个值。

    3.聚合及聚合根(aggregate、aggregate root):

            聚合是用来定义领域对象所有权和边界的领域模式。聚合的作用是帮助简化模型对象间的关系。聚合,它通过定义对象之间清晰的所属关系和边界来实现领域模型的内聚,并避免了错综复杂的难以维护的对象关系网的形成。聚合定义了一组具有内聚关系的相关对象的集合,我们把聚合看作是一个修改数据的单元。

            划分aggregation是对领域模型的进一步深化,aggregation能阐释领域模型内部对象之间的深层关联.对aggregation的划分会直接映射到程序结构上.比如:ddd推荐按aggregation设计model的子包.每个aggregation配备一个repository.aggregation内部的非root对象是通过导航获得的.        

            一个聚合是一组相关的被视为整体的对象。每个聚合都有一个根对象(聚合根实体),从外部访问只能通过这个对象。根实体对象有组成聚合所有对象的引用,但是外部对象只能引用根对象实体。

             只有聚合根才能使用仓储库直接查询,其它的只能通过相关的聚合访问。如果根实体被删除,聚合内部的其它对象也将被删除。

             通常,我们把聚合组织到一个文件夹或一个包中。每一个聚集对应一个包,并且每个聚集成员包括实体、值对象,domain事件,仓储接口和其它工厂对象。

     

    聚合有以下一些特点:

      1. 每个聚合有一个根和一个边界,边界定义了一个聚合内部有哪些实体或值对象,根是聚合内的某个实体;

      2. 聚合内部的对象之间可以相互引用,但是聚合外部如果要访问聚合内部的对象时,必须通过聚合根开始导航,绝对不能绕过聚合根直接访问聚合内的对象,也就是说聚合根是外部可以保持对它的引用的唯一元素;

      3. 聚合内除根以外的其他实体的唯一标识都是本地标识,也就是只要在聚合内部保持唯一即可,因为它们总是从属于这个聚合的;

      4. 聚合根负责与外部其他对象打交道并维护自己内部的业务规则

      5. 基于聚合的以上概念,我们可以推论出从数据库查询时的单元也是以聚合为一个单元,也就是说我们不能直接查询聚合内部的某个非根的对象;

      6. 聚合内部的对象可以保持对其他聚合根的引用;

      7. 删除一个聚合根时必须同时删除该聚合内的所有相关对象,因为他们都同属于一个聚合,是一个完整的概念。

    如何识别聚合?

            聚合中的对象关系是内聚的,即这些对象之间必须保持一个固定规则,固定规则是指在数据变化时必须保持不变的一致性规则。

            当我们在修改一个聚合时,我们必须在事务级别确保整个聚合内的所有对象满足这个固定规则。

            作为一条建议,聚合尽量不要太大,否则即便能够做到在事务级别保持聚合的业务规则完整性,也可能会带来一定的性能问题。

            有分析报告显示,通常在大部分领域模型中,有70%的聚合通常只有一个实体,即聚合根,该实体内部没有包含其他实体,只包含一些值对象;另外30%的聚合中,基本上也只包含两到三个实体。这意味着大部分的聚合都只是一个实体,该实体同时也是聚合根。

     

    如何识别聚合根?

      如果一个聚合只有一个实体,那么这个实体就是聚合根;如果有多个实体,可以思考聚合内哪个对象有独立存在的意义并且可以和外部直接进行交互。

           并不是所有的实体都是聚集根,但只有实体才能成为聚集根。

    4.工厂(factories):

           工厂用来封装创建一个复杂对象尤其是聚合时所需的知识,作用是将创建对象的细节隐藏起来。客户传递给工厂一些简单的参数,然后工厂可以在内部创建出一个复杂的领域对象然后返回给客户。当创建 实体和值对象复杂时建议使用工厂模式。

           不意味着我们一定要使用工厂模式。如果创建对象很简单,使用构造器或者控制反转/依赖注入容器足够创建对象的依赖。此时,我们就不需要通用工厂模式来创建实体或值对象。

           良好工厂的要求:

           每个创建方法都是原子的。一个工厂应该只能生产透明状态的对象。对于实体,意味着创建整个聚合时满足所有的不变量。

          一个单独的工厂通常生产整个聚合,传出一个根实体的引用,确保聚合的不变量都有。如果对象的内部聚合需要工厂,通常工厂方法的逻辑放在在聚合根上。这样对外部隐藏了聚合内聚的实现,同时赋予了根确保聚合完整的职责。如果聚合根不是子实体工厂的合适的家,那么继续创建一个单独的工厂。

     

    5.仓储(repositories):

            仓储是用来管理实体的集合。

             仓储里面存放的对象一定是聚合,原因是domain是以聚合的概念来划分边界的;聚合作为一个整体概念,要么一起被取出来,要么一起被删除。外部访问不会单独对某个聚合内的子对象进行单独操作。因此,我们只对聚合设计仓储。

             仓储还有一个重要的特征就是分为仓储定义部分和仓储实现部分,我们在领域模型中定义仓储的接口,而在基础设施层实现具体的仓储。也符合按照接口分离模式在领域层定义仓储库接口的原则。

            注意:repositories本身是一种领域组件,但repositories的实现却不是领域层中的。

    respositories和dao:

             dao和repository在领域驱动设计中都很重要。dao是面向数据访问的,是关系型数据库和应用之间的契约。

            repository:位于领域层,面向aggregation root。repository是一个独立的抽象,使用领域的通用语言,它与dao进行交互,并使用领域理解的语言提供对领域模型的数据访问服务的“业务接口”。

      dao方法是细粒度的,更接近数据库,而repository方法的粒度粗一些,而且更接近领域。领域对象应该只依赖于repository接口。客户端应该始终调用领域对象,领域对象再调用dao将数据持久化到数据 存储中。

      处理领域对象之间的依赖关系(比如实体及其repository之间的依赖关系)是开发人员经常遇到的典型问题。解决这个问题通 常的设计方案是让服务类或外观类直接调用repository,在调用repository的时候返回实体对象给客户端。

    6.服务(services):

             服务这个词在服务模式中是这么定义的:服务提供的操作是它提供给使用它的客户端,并突出领域对象的关系。

             所有的service只负责协调并委派业务逻辑给领域对象进行处理,其本身并真正实现业务逻辑,绝大部分的业务逻辑都由领域对象承载和实现了。

             service可与多种组件进行交互,这些组件包括:其他的service、领域对象和repository 或 dao。

             通常,应用中一般包括:domain模型服务和应用层服务:

            *  domain services encapsulate domain concepts that just are not naturally modeled as things.

            *  application services constitute the application, or service, layer.

            当一个领域操作被视为一个重要的领域概念,一般就应该作为领域服务。 服务应该是无状态的。

            设计实现领域服务来协调业务逻辑,只在领域服务中实现领域逻辑的调用。

            领域服务逻辑须以非常干净简洁的代码实现。因此,我们必须实现对领域低层组件的调用。通常应用的调用,例如仓储库的调用,创建事务等,不应该在这里实现。这些操作应该在应用层实现。

              通常服务对象名称中都应包含一个动词。 service接口的传入传出参数也都应该是dto,可能包含的工作有领域对象和dto的互转换以及事务。

          服务的3个特征:

      a. 服务执行的操作涉及一个领域概念,这个领域概念通常不属于一个实体或者值对象

      b. 被执行的操作涉及到领域中其它的对象

      c. 操作时无状态的

    推荐:最好显式声明服务,因为它创建了领域中一个清晰的特性,封装了一个概念领域层服务和基础设施层服务:均建立在领域实体和值对象的上层,以便直接为这些相关的对象提供所需的服务;

     

    领域服务与domain对象的区别

            一般的领域对象都是有状态和行为的,而领域服务没有状态只有行为。需要强调的是领域服务是无状态的,它存在的意义就是协调领域对象共同完成某个操作,所有的状态还是都保存在相应的领域对象中。

            通常,对开发人员来说创建不应该存在的服务相当容易;要么在服务中包含了本应存在于领域对象中的领域逻辑,要么扮演了缺失的领域对象角色,而这些领域对象并没有作为模型的一部分去创建。

     

    7.domain事件

            domain event模式最初由udi dahan提出,发表在自己的博客上:http://www.udidahan.com/2009/06/14/domain-events-salvation/

            企业级应用程序事件大致可以分为三类:系统事件、应用事件和领域事件。领域事件的触发点在领域模型(domain model)中。它的作用是将领域对象从对repository或service的依赖中解脱出来,避免让领域对象对这些设施产生直接依赖。它的做法就是当领域对象的业务方法需要依赖到这些对象时就发出一个事件,这个事件会被相应的对象监听到并做出处理。

            通过使用领域事件,我们可以实现领域模型对象状态的异步更新、外部系统接口的委托调用,以及通过事件派发机制实现系统集成。另外,领域事件本身具有自描述性。它不仅能够表述系统发生了什么事情,而且还能够描述发生事件的动机。

             domain事件也用表进行存储。

    8.DTO

           dto- datatransfer object(数据传输对象):dto在设计之初的主要考量是以粗粒度的数据结构减少网络通信并简化调用接口。

    领域驱动架构与n层架构设计

    领域驱动架构

            eric  evans的“领域驱动设计- 应对软件的复杂性“一书中描述和解释了建议的n层架构高层次的图:

     

    user interface:

            该层包含与其他系统/客户进行交互的接口与通信设施,在多数应用里,该层可能提供包括web services、rmi或rest等在内的一种或多种通信接口。该层主要由facade、dto和assembler三类组件构成,三类组件均是典型的j2ee模式。

            dto的作用最初主要是以粗粒度的数据结构减少网络通信并简化调用接口。在领域驱动设计中,采用dto模型,可以起到隐藏领域细节,帮助实现独立封闭的领域模型的作用。

            dto与领域对象之间的相互转换工作多由assembler承担,也有一些系统使用反射机制自动实现dto与领域对象之间的相互转换,如apache common beanutils。

            facade的用意在于为远程客户端提供粗粒度的调用接口。facade本身不处理任何的业务逻辑,它的主要工作就是将一个用户请求委派给一个或多个service进行处理,同时借助assembler将service传入或传出的领域对象转化为dto进行传输。

     

    application:

             application层中主要组件就是service。这里需要注意的是,service的组织粒度和接口设计依据与传统transaction script风格的service是一致的,但是两者的实现却有质的区别。

      transaction script(事务脚本)的核心是过程,通过过程的调用来组织业务逻辑,业务逻辑在服务(service)层进行处理。大部分业务应用都可以被看成一系列事务。

             transaction script的特点是简单容易理解,面向过程设计。  如果应用相对简单,在应用的生命周期里不会有基础设施技术的改变,尤其是业务逻辑很少会变动,采用transaction script风格简单自然,性能良好,容易理解。

            transaction script的缺点在于,对于复杂的业务逻辑难以保持良好的设计,事务之间的冗余代码不断增多。应用架构容易出现“胖服务层”和“贫血的领域模型”。同时,service层积聚越来越多的业务逻辑,导致可维护性和扩展性变差

      领域模型属于面向对象设计,领域模型具备自己的属性行为和状态,领域对象元素之间通过聚合配合解决实际业务应用。可复用,可维护,易扩展,可以采用合适的设计模型进行详细设计。缺点是相对复杂,要求设计人员有良好的抽象能力。

            transactionscript风格业务逻辑主要在service中实现,而在领域驱动设计的架构里,service只负责协调并委派业务逻辑给领域对象进行处理。因此,我们可以考察这一点来识别系统是transaction script架构还是domain model架构。在实践中,设计良好的领域设计架构在开发过程中也容易向transaction script架构演变。

     

    domain:

            domain层是整个系统的核心层,该层维护一个使用面向对象技术实现的领域模型,几乎全部的业务逻辑会在该层实现。domain层包含entity(实体)、valueobject(值对象)、domain event(领域事件)和repository(仓储)等多种重要的领域组件。

    infrastructure:

            infrastructure(基础设施层)为interfaces、application和domain三层提供支撑。所有与具体平台、框架相关的实现会在infrastructure中提供,避免三层特别是domain层掺杂进这些实现,从而“污染”领域模型。infrastructure中最常见的一类设施是对象持久化的具体实现。

     

    n层架构设计

            层(layers)被视为构成应用或服务的水平堆叠的一组逻辑上的组件。它们帮助区分完成不同任务的组件,提供一个最大化复用和可维护性的设计。简言之,是关于在架构方面应用关注点分离的原则。         在传统的多层架构中,每个解决方案的组件必须分隔到不同的层。每层的组件必须内聚而且有大约相同的抽象级别。每个一级层应该和其他的一级层松耦合。

            从最底层的抽象级别看,例如第1层。这是系统的基础层。这些抽象的步骤是一步一步的最后到最顶层。

            多层应用的关键在于对依赖的管理。传统的多层架构,层内的组件只能和同级或者低级层的组件交互。这有利于减少不同层内组件的依赖。通常有两种多层架构的设计方法:严格和灵活的。          *   “严格的层设计”限定层内的组件只能和同一层、或者下一层的组件通信。即第n层只能和第n-1层交互,n-1层只能和n-2层交互,等等。

             *  “灵活的层设计”允许层内的组件和任何低级别层交互。这种设计中,第n层可以和n-1,n-2层交互。

            这种设计由于不需要对其他层进行重复的调用,从而可以提高性能。然而,这种设计不提供层之间的同层隔离级别,使得它难以在不影响多个高级层的时候替换一个低级的层。

            由于层之间是通过定义明确的接口进行交互这一事实,很容易为各层添加替代的实现(例如 mock  and stubs)。

             因为高层的组件只能和底层的交互,在单独的组件上进行测试是很容易的。

    使用层的好处  -  功能容易确定位置,解决方案也就容易维护。层内高内聚,层间松耦合使得维护/组合层更容易。 -  其他的解决方案可以重用由不同层暴露的功能。 -  当项目按逻辑分层时,分布式的部署更容易实现。 -  把层分布到不同的物理层可以提高可伸缩性;然后这一步应该进行仔细的评估,因为可能对性能带来负面影响。

    面向领域架构的分层:

            在面向领域架构中,关键是要清楚界定和分离领域模型层和其余的层。

    领域驱动与项目开发

             一般适合结合使用scrum(适用于项目管理)和xp(适用于软件开发目标)方法对处理ddd实施项目。敏捷方法注重于交付商业价值,而ddd侧重于结合软件系统和业务模型。此 外,就ddd迭代的特性来说,scrum或dsdm这样的敏捷方法对项目管理来说也是更好的框架。

           ddd迭代周期的项目管理模型如图所示。

    本图根据《domain driven design and development in practice》一文中插图进行了部分修改。

      领域建模结束时可以开始领域驱动设计。关于如何开始实现领域对象模型,ramnivas laddad推荐如下的步骤。他强调要更侧重于领域模型中的领域对象,而不是服务。

           *   从领域实体和领域逻辑开始。

           *   不要一开始就从服务层开始,只添加那些逻辑不属于任何领域实体或值对象的服务。

           *   利用通用语言、契约式设计(dbc)、自动化测试、  ci和重构,使实现尽可能地与领域模型紧密结合。

     

    设计领域模型的一般步骤:

           1.   根据需求建立一个初步的领域模型,识别出一些明显的领域概念以及它们的关联,关联可以暂时没有方向但需要有(1:1,1:n,m:n)这些关系;可以用文字精确的没有歧义的描述出每个领域概念的涵义以及包含的主要信息;

           2.   分析主要的软件应用程序功能,识别出主要的应用层的类;这样有助于及早发现哪些是应用层的职责,哪些是领域层的职责;

           3.   进一步分析领域模型,识别出哪些是实体,哪些是值对象,哪些是领域服务;

           4.   分析关联,通过对业务的更深入分析以及各种软件设计原则及性能方面的权衡,明确关联的方向或者去掉一些不需要的关联;

           5.   找出聚合边界及聚合根,这是一件很有难度的事情;因为你在分析的过程中往往会碰到很多模棱两可的难以清晰判断的选择问题,所以,需要我们平时一些分析经验的积累才能找出正确的聚合根;

           6.   为聚合根配备仓储,一般情况下是为一个聚合分配一个仓储,此时只要设计好仓储的接口即可;

           7.   走查场景,确定我们设计的领域模型能够有效地解决业务需求

           8.   考虑如何创建领域实体或值对象,是通过工厂还是直接通过构造函数;

           9.   停下来重构模型。寻找模型中觉得有些疑问或者是蹩脚的地方,比如思考一些对象应该通过关联导航得到还是应该从仓储获取?聚合设计的是否正确?考虑模型的性能怎样,等等;

             领域建模是一个不断重构,持续完善模型的过程,大家会在讨论中将变化的部分反映到模型中,从而是模型不断细化并朝正确的方向走。

      从设计和实现的角度来看,典型的ddd框架应该支持以下特征。

           *   应该是一个以pojo为基础的架构。

           *   应该支持使用ddd概念的业务领域模型的设计和实现。

           *   应该支持像依赖注入(di)和面向方向编程(aop)这些概念的开箱即用。

           *   与单元测试框架整合。

           *   与其它java/java ee框架进行良好的集成,比如jpa、hibernate、toplink等。

    一些反模式:

           *   贫血的领域对象

           *   重复的dao

           *   肥服务层:服务类在这里最终会包含所有的业务逻辑。

           *   依恋情结(feature envy):函数对某个类的兴趣高过对自己所处类的兴趣。

    一些思考

    1.   建立完整自封闭的领域模型。

            领域驱动架构相对比较容易理解,但建立一个完整自封闭的领域模型却很困难。“领域模型”是一个针对业务逻辑抽象的分析模型,它反映出对领域问题的整体描述。领域模型不是编程的实现模型,而是一组抽象概念的集合。一个领域概念不一定映射成一个类,也有可能会映射很多的类(包括多个实体或值对象)。领域需求的最初细节,在功能层面通过领域专家的讨论得出。领域专家并不一定需要熟知软件开发领域的知识,相反强调的是具有领域中的相关知识。领域需求在相互讨论中不断得到细化,还有可能在开发过程出现需求的反复或变更,这都要求领域模型的建立完善是一个反复重构的过程。敏捷开发是一种应对快速变化的需求的一种软件开发能力。强调程序员团队与业务专家之间的紧密协作、面对面的沟通(认为比书面的文档更有效)、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法。故采用敏捷开发有利于领域模型的建立完善,以更能符合用户的实际需求。

          关于领域模型分析存在有多种分析方法。也许并不是能经常能有机会去实践这些分析方法或分析领域模型。但关于领域驱动架构的理解,有助于帮助我们去理解领域驱动的设计,实现一些高内聚、低耦合的代码实现。

    2.  领域服务建模

              建立和识别领域服务也比较容易出错。通常的ssh分层架构与领域驱动架构相近,而ssh架构开发更容易导致transaction script架构而非领域驱动架构。在ssh分层架构上,开发人员更容易建立”贫血”模型,而在service里实现业务逻辑。而ddd强调“充血模型”,“薄”service层。建立领域服务需要识别出领域业务逻辑,并将业务实现到领域模型中。一方面,业务需求充满着变化,在开发过程中难以把握。当业务不明需求不清时,“贫血模型”就更容易被人接受。另一方面,在构建领域模型时,orm映射显示十分重要并且也非常复杂,包括类继承体系与数据库的映射,抓取策略和缓存管理在内的一系列问题等.“贫血模型”有时会简化这种映射关系,同时,在处理对象依赖关系上显得更加灵活性。而领域模型强调了领域边界,对领域对象的访问总是通过聚合根开始,在有时候,模型的某些遍历会带来更大的性能和稳定性上的问题。而解决这些问题时,又常常会从实效性上出发而牺牲模型个别的清晰性和纯洁性。

    3.领域对象、领域服务以及repository之间的互相依赖

            在实际开发中,开发人员会经常需要处理领域对象之间的依赖关系,以及领域对象与repository间的依赖。通常可能的方案是让service或façade直接调用repository,从而获得返回的领域对象。这种方式导致各层间的依赖,通常我们应该考虑解耦这种依赖。当前实现组件解耦常用的技术无非是:控制反转(ioc)、依赖注入(di)、面向方面编程(aop)以及分布式服务接口。因此,解决依赖的一种思路利用di或aop将repository和服务注入到领域对象中。spring框架提供了相关的机制。在spring环境中,利用spring实例化对象,注入依赖,将服务、repository等领域对象联系起来。

     

    阿里盒马领域驱动设计实践

    领域驱动设计在美团点评业务系统的实践

    文章来源:https://www.cnblogs.com/firstdream/p/8669611.html

    展开全文
  • 大型企业中业务中台建设思考

    千次阅读 2020-05-20 09:44:52
    大型企业中业务中台建设思考 在十几年的IT系统开发中,经历了从servlet技术、struts框架、Spring架构、模板技术、到现在的微服务、前后端分离、Serverless、AI技术等,我发现每一次的技术更新都是对复杂技术进一步的...

    大型企业中业务中台建设思考

    近年来从互联网领域到传统行业竟争变得日益激烈,消费者的层次结构和个性化需求在快速发生变化,企业为了应对这种变化不得不进行业务的快速迭代,在此背景下IT行业里中台的概念逐渐火了起来,大家都在谈论或实施中台化战略,中台有什么魔力能有这样的号召力,各类企业特别是跨业态的集团化企业都希望通过中台战略解决自身问题,但是我们也看到一些企业在实施中台项目中出现了严重的问题和偏差,阿里巴巴张勇曾说过:“如果一个企业奔着中台做中台,就是死”,中台最早是由阿里提出的一种IT架构理念和方法,其实中台思想古来有之,只是在互联网时代给它赋予了新的涵意。

    在这里插入图片描述
    那么什么是中台呢?我认为日常生活中我们每天能都接触到中台的服务,中台能对资源进行向下整合,向上共享复用,前段时间同事在贝壳上买了一套商品房,服务体验非常好,贝壳将线下各类房产中介公司的房源进行了整合,形成统一的房源池,提供真实的房源、房价和小区的近期成交数据,客户只需要在贝壳一个平台找合适自己的房子,贝壳还整合了各家银行的工作人员在贝壳交易中心上班,那里每一家银行有一个办公室,客户可以自己选择在哪个银行贷款,甚至将房管局、税务局等过户手续部门都整合在贝壳交易中心,这在没有贝壳前是完全不可想像的,从中可以看出贝壳平台就是客户与房源的中台,客户与银行、房管局、税务局的中台,贝壳将买房需要的找房、网签、贷款、交税和过户的手续都放在贝壳交易中心完成,全流程实现了线上化和移动化,极大的方便了客户、房东和中介公司办理业务。
    中台思想我理解就是一层层对细节的抽象,这和IT系统建设中抽象设计模式的道理一样,将软件中有共性的、可复用的部分提炼出来,快速满足多业务场景的需求和发展,企业中的业务中台将后台资源进行整合和抽象,并向前台提供简单可重用的共享服务能力,实现了后台业务资源到前台易用能力的转化,这种中台思想能不能解决企业中碰到的瓶颈呢?

    我从事IT系统研发十几年,负责了多个大型信息平台的建设,也见证了国内企业IT架构十几年的发展历程,从解决一个业务问题的应用系统发展到以数据平台为基础支撑的架构,到互联网微服务和中台架构,背后总是用户的迫切需求驱动着企业响应能力的提升,技术的飞速发展对于各方都是个极大的挑战。技术层面经历了从上古时代的EJB、Servlet、Struts、Spring架构、模板技术、到现在的微服务、前后端分离、Serverless、AI技术等,我发现每一次的技术更新都是对复杂问题进一步的抽象和复用,让使用者不需要关心具体的实现方式,只需要通过简单的集成就能使用,对于将来的IT技术发展我估计也是这样的发展方向,IT技术会逐步下沉到更底层,对外输出的仅仅是傻瓜化的工具,让非专业的业务人员参与到IT建设中来,甚至是系统功能的创造者。比如我们讲的QuickBI和DataV这两个BI工具,开发人员只需要把基础数据提供出来,剩下的事都交给工具和业务人员完成,这不仅仅是技术的升级,甚至已经影响到将来全社会的分工协作界限。技术可以一次次抽象出来复用,那业务模块是不是也可以这样干?

    从理论上说将业务模块抽象到合适的粒度是有可能实现的,服务铁路旅客的业务能力,能不能直接挪到航空旅客用?这就是业务中台解决的问题。但很明显由于业务和组织存在更高复杂度和差异度,所以会非常非常难。很多传统企业没有自己的研发团队,像很多国有企业IT系统基本都是依靠第三方供应商提供和服务支撑,而且大多是以传统项目制和采购产品的方式经过多年实施逐步形成的,这种方式基本以甲方出需求,乙方设计实施,甲方验收的流程建设,是由业务和职能单位发起针对自己的问题确定方案,这些单位很难主动去考虑与其它业务实体间的协同交互,这种组织架构形成了部门墙,数据和业务也是烟囱式的,相互协作困难。如果大家能在一个平台上运行,用户数据、产品数据、支付数据、订单数据进行统一处理,这样数据就可以在平台上流动起来,多业务实体间的协同服务,简化旅客出行的流程是完全可能的。对用户来说每多一个操作步骤,就会多损失一半的用户。但有一个很大的风险是组织结构的适应调整,中台项目失败很大原因就是资源得不到满足。阿里巴巴中台战略的成功也是组织中台的不断调整和完善作为保障的。
    以前一个企业要建信息平台一般分为前台和后台。很多企业的后台系统在立项建设时不是为了服务于前台系统也不面向最终用户,而更多的是为了实现管理手段的电子信息化,提升企业的管理效率。这类系统一部分是当年花大价钱采购,需要每年支付大量的服务费,版本老旧变更困难;一部分自建的年久失修同样变更困难,对业务的响应慢,动不动改个小功能还要花一大笔费用,从集团公司最顶层看各成员企业几百个信息系统,很多系统都是这样,不仅仅是慢和贵,更重要的是被系统供应商给绑架了,很多系统代码的产权是谁的都说不清楚,而且几乎看不到哪个系统有扩容规划、灾备演练、降级限流等架构的实际落地和执行。
    此时前台和后台就像汽车上两个转速不协调的齿轮,赛车手希望前台的四个轮胎转速越快越好,而发动机作为一台汽车的心脏它的齿轮转速则不是越高越好,它需要考虑车速、档位、油耗、温度和安全等综合指标,中台就是找到一个最合理的平衡点来保证前后的协调一致,想要快速响应前端用户的大量需求,要求能够快速创新迭代,所以前端要求转速越快越好;后台由于对应的是相对稳定的后端资源,系统变更困难越稳定越好,希望转速越慢越好。随着企业业务的不断发展,前后台架构导致齿轮不匹配的问题就逐步显现出来。后台变更越来越困难,但还要响应用户持续不断的需求,导致业务逻辑直接在前台实现,致使前台系统不断膨胀和复杂,形成了一个个烟囱式系统,业务沉淀不下来,系统交互困难,用户响应能力低下。

    中台的出现将前台与后台的齿轮转速进行适配。将后台资源集成开放响应用户的需求。将前台应用中的稳定通用业务能力逐步下沉中台,提高前台的用户响应能力;又可以将后台系统中需要频繁变化或是需要被前台直接使用的业务能力抽取到中台实现,为前台提供更强大的炮火支援。2020年新冠疫情爆发,全国驰援武汉,我们国家发挥了强大的中台整合能力,一方有难八方支援,政府从各地组织医疗资源和抗疫物资,通过疫情数据和病症情况的实时监控,不停的迭代医治方案,很快控制住了疫情的发展,体现了在中台的支持下前台快速的应变能力,一省驰援一市的方案体现了微服务化的分而治之架构,国家将抗疫的经验分享给其它国家,援助医疗物资体现了中台的共享复用,但我们从数据上了解还有很多发达国家对疫情的控制没到位,更能体现出IT中台架构的建设风险和运营的风险都比较大。

    从第一次接触业务中台的概念到负责中台设计、实施、上线运行,我认为中台概念非常合理先进,从架构的角度看,对企业数字化转型和IT架构一下子清晰了很多,可以从更高的层次分析和把握整个企业的IT架构,前台业务敏捷迭代快速响应用户需求,中台业务稳固支撑。反过来前台的大量需求不断的滋养中台的成长和完善。不过在企业里真实情况真是这样吗?真正能做好、运营好业务中台的可能并不多,提出中台概念的阿里巴巴也是经过了十几年的沉淀才达到目前的阶段,能够想象到过程一定很不容易。阿里巴巴是以战略提出的中台架构,京东以组织架构中台化开始,不难想象某个集团企业要开发上线一个中台的信息系统来解决企业存在的问题,我个人认为失败的风险极大。我从技术的维度将实施业务中台的一些经验教训进行了分析和总结,后期我会尽最大化归纳整理一个高可靠、高性能、低成本、低运维的业务中台模型。提几点我对实施业务中台的建议和思考:

    1. 企业中存在很多相同或类似的业务需求,通过IT技术将这些业务功能抽象化,下沉为通用的、复用的业务能力,全面支持各业务线的快速发展,并提供业务创新的能力平台和底座,这是实施业务中台的核心价值。所以业务中台是为业务服务的,各业务中心要了解和掌握你所支撑的业务具体情况是什么样子,对业务知识和流程要有深刻的认识。
    2. 业务中台化不会有一套拿来改改就能用的方案,必须具体情况具体分析,中台化的过程不出意外一定是痛苦和艰难的。需要让企业的主要负责人知道什么是中台,信息系统中台化后组织结构的调整和业务流程重组可执行吗?企业的业务发展到了必须实施中台战略吗?
    3. 能用微服务解决就暂时用微服务技术去支撑业务的发展,如果微服务能解决还要上中台的话,我个人不太推荐。用微服务的技术支撑了业务中台的运行,我们上线了业务中台后也在逐步的调整和适应,步子迈的稍微大了一点,业务中心分的太细导致复杂的业务依赖关系和分布式事务的问题,所以也在对业务中心进行从细到粗的合并,一些镀金的功能以微服务的方式运行提供能力支撑。
    4. 中台化要用互联网思维建设,选择更容易实施的业务领域开始,而不是全面开花,如果是大型集团化企业要实现整体架构中台化,可能在市场上就没有这样一个承建商敢承接,另一方面不能抱着建信息系统的项目制实施,应通过敏捷迭代的方式每个月,甚至每周每天都能看到成果和问题,逐步迭代完善,采用小步快跑、快速试错的方式实施,如果等到上线的时候才发现问题那就比较麻烦,涉及的业务太全面,可变因素和不确定性就会很多,失败的风险相应也更大。
    5. 中台项目的实施要有自己的业务专家、IT架构师和研发团队,中台建设是个长期的工作,它需要逐步成长和完善,如果直接交给IT承建商去实施,风险有点大,我们在建设中台的时候我作为集团公司IT架构师全程参与并决策整个架构的设计,工作细到每个业务中心的数据模型和字段,每天对承建商的代码级评审,而且通过外包的方式组建了一只自己的研发团队参与到中台和业务应用的开发中,我们业务中台的验收标准是上线的那一天就是承建商撤离的时间点,也不需要承建商二期以及运维,需要完全由自己的外包研发团队承接,这个其实很容易,因为自己的外包研发团队和承建商的研发团队整个实施过程都是一起开发,分工协作,比如承建商做订单业务中心,自有外包团队做支付中心。另一方面从业务上由我们信息部门的业务经理按条线分工去现场了解、收集和分析需求,这样可以把握需求的范围和质量,因为我们的业务经理是都是从机场一线上来的,最懂业务最了解现场情况,而不是直接将需求管理交给承建商去做。
    6. 要处理好业务中台和业务应用这两层之间的关系,很多传统企业没有自己的开发团队,上层的业务应用层可能有几十个IT厂家要基于中台开发和改造。有专业化比较高的应用,还有一些应用直接使用的SAAS服务,如何在架构上处理好还真不容易,需要从多个维度来解决。我们在开发业务中台时人为的将项目团队分为两个组,一组专门做业务中心,另一组则开发新的业务应用,当业务应用基于业务中心开发完成时,那么基于业务中心开发业务应用的标准就出来的。另一方面从架构上也要适应业务应用层的多样性。
    7. 企业建设业务中台不应该完全从IT技术层面考虑,需要从技术、业务、组织和运营多个维度协同推进,而不单单是IT系统的一个维度。业务中台只是支持业务场景的手段,并将多渠道的业务能力抽象沉淀下来,业务中台的逐步成长完善也需要独立的组织进行运营,平台型组织是业务中台的重要基础也是企业转型的方向,前后台业务的拉通是平台型组织的发展大趋势,阿里中台之所以成功不仅是技术,更是敏捷的组织变革,阿里提出“大中台、小前台”的中台战略后,进行过十几次组织调整和部门合并,都是为拉通前中后台提供了基础。
    8. 中台架构的实施落地推荐从易到难逐步实施,从最简单的资源中台开始,到技术中台、数据中台->业务中台->组织中台,最终完成企业架构的中台化。这个过程是漫长的也是曲折的,我们在两年的中台建设中,碰到的问题大多与技术无关,更多出现在组织的边界划分上,我作为IT架构师更多的努力是从技术手段去解决碰到的问题,但往往在关键的节点是绕不开组织的问题。我曾经看到别人写的一段话:“组织可能不是中台建设的阻碍,而恰恰是中台建设的本质”,只有亲身经历过中台建设的人,才能正真体会出中台早已超出了技术的范畴。

    设计再完美的架构在建设过程中也会有变化,因为实施各阶段面临的影响因素非常多,所以变是正常的,不变才是有问题的。大型信息系统都是从小到大一步步完善,在每个阶段都会遇到各类系统性和业务类问题,然后在不断的解决这些问题,所以架构是由业务规模驱动而逐步演进完善的,当然IT架构也不应过度设计而舍本逐末。

    展开全文
  • 0.澄清基本概念I.大型IT企业:指对外提供IT相关的软硬件产品及服务的公司,员工至少在万人以上。II.数据平台:指大型IT企业用来为自身服务为主,担负数据存储、处理、分析业务和软硬件综合。主要针对内部服务,不...
  • 大数据时代,利用大数据驱动业务发展,打造企业新型能力势在必行工信部的数据显示:“中国制造业约占整个世界制造业20%的份额,在500余种主要产品中,我国有220多种产量位居世界第一。2014年,我国共有100家企业入选...
  • 巨石崩裂时,有人看见了恐惧,有人看见了光。...今天,云徙科技召开「数in未来 一起发光」新品线上发布会,以3D科技秀的方式向企业伙伴及业界朋友正式介绍这款面向成长型企业用户产品「数盈·新营销中台...
  • Linux下USB Core的工作原理及设备驱动技术 Linux下USB Core的工作原理及设备驱动技术 Linux以其稳定、高效、易定制、硬件支持广泛、源代码开放等特点,已在嵌入式领域迅速崛起,被国际上许多大型的跨国企业...
  • 领域驱动设计,为何又死灰复燃了?

    万次阅读 热门讨论 2018-07-18 07:15:00
    张逸,曾先后就职于中兴通讯、惠普 GDCC、中软国际、ThoughtWorks 等大型中外企业,任职角色为高级软件工程师、架构师、技术总监、首席咨询师。 一、领域驱动设计为何又死灰复燃焕发青春? 领域驱动设计(Domain ...
  • 来源:中国电子报“忽如一夜春风来,千树万树梨花开。” 这首诗形容当前“中台”概念的风靡非常恰当。IT圈里不乏新的概念、新的“网红”,如今,“中台”一词占据了C位,成为软硬...
  • 大型传统企业如何向人工智能转型?

    千次阅读 2018-03-02 00:00:00
    来源:FT中文网在新一波技术浪潮的冲击下,以AI、大数据、云计算、物联网、5G通信等一系列技术为代表的“技术簇”所引发的革命对人类社会的影响将是全面且深刻的。每一个商业单元都面对这样的机遇:能否通过对新技术...
  • 领域驱动战略设计实践

    千次阅读 2018-11-26 13:16:48
    国内关于领域驱动设计(Domain Driven Design,DDD)的原创书籍少之又少,甚至可以说没有,作者结合十余年实践领域驱动设计的经验与心得,并糅合了 DDD 社区最新发展的理论知识与最佳实践,策划了《领域驱动设计实践...
  • 大型网站技术架构-入门梳理

    千次阅读 2017-01-18 21:50:20
    罗列了大型网站架构涉及到的概念,附上了简单说明
  • (一)数据挖掘概念技术——韩家炜

    万次阅读 多人点赞 2017-09-04 11:49:08
    第三版 25页 数据挖掘又称知识发现...数据挖掘可以看作信息技术自然进化的结果。数据库和数据管理产业在一些关键功能的开发上不断发展: 数据收集和数据库创建 数据管理(包括数据存储和检索、数据库事务处理) 高级数
  • [转]微服务概念解析

    千次阅读 2016-04-05 14:44:55
    “微服务架构”概念的提出已经有很长一段时间了,但在最近几年却开始频繁地出现。微服务架构是一种特定的软件应用程序设计方式——将大型软件拆分为多个独立可部署服务组合而成的套件方案。
  • 来源:FT中文网在新一波技术浪潮的冲击下,以AI、大数据、云计算、物联网、5G通信等一系列技术为代表的“技术簇”所引发的革命对人类社会的影响将是全面且深刻的。每一个商业单元都面对这样的机遇:能否通过对新技术...
  • 4.1 试述多个异构信息源的集成,为什么许多公司更喜欢更新驱动的方法(构造和使用数据仓库),而不是查询驱动的方法(适用包装器和集成器)。 描述查询驱动的方法比更新驱动的方法更可取的情况。 对于决策查询和...
  • 云计算云存储的一些基本概念

    万次阅读 多人点赞 2018-04-12 20:10:04
    我们在学习云计算和云存储之前,需要先了解一些很常见的基本概念,否则在学习过程中和选型时会比较晕。 云计算的三种服务模式:IaaS,PaaS和SaaS 云的分层 任何一个在互联网上提供其服务的公司都可以叫做云计算...
  • Ceph OSD的架构实现由物理磁盘驱动器、Linux文件系统和Ceph OSD服务组成,对于Ceph OSD Deamon而言,Linux文件系统显性的支持了其拓展性,一般Linux文件系统有好几种,比如有BTRFS、XFS、Ext4等,BTRFS虽然有很多...
  • 从此之后的10年(今年是2016年)人们云计算的理解,也从最早概念的、技术的、遥远的“名词”,演变成了今天落地的、商业属性的、身边的“事物”。说它是落地的:无论是Amazon、谷歌这样的互联网公司,还是传统的政府...
  • 101 云计算基础概念

    千次阅读 2017-04-13 23:06:42
    1.技术驱动 2.需求驱动 3.商业模式驱动 海量的数据和终端 IT的复杂性、商业延迟也是促进云计算产生的一个因素2.云计算的概念 —商业视角 云计算=信息电厂 –技术视角 云计算=计算/存储的网络 云计算分为狭义...
  • 云计算的概念和价值

    万次阅读 多人点赞 2018-05-15 22:28:03
    云计算的概念: 云计算(cloud computing)是一种按是使用量付费的模式,这种模式是可用的、便捷的、按需的网络访问,进入可配置的计算机资源共享池(资源包括网络,服务器,存储,应用软件,服务),这些资源能够被...
  • 如何系统学习领域驱动设计(DDD)?

    千次阅读 热门讨论 2018-07-17 11:47:27
    作者简介 张逸,曾先后就职于中兴通讯、惠普 GDCC、中软国际、ThoughtWorks 等大型中外企业,任职角色为高级软件工程师、架构师、技术总监、首席咨询师。 精通包括 Java、Scala、Python、C#、JavaScript、Ruby ...
  • 谷歌企业文化建设分析

    千次阅读 2017-12-05 17:09:35
    简要分析谷歌作为一家科技巨头的企业文化。
  • 商业智能SAAS走向中小企业

    千次阅读 2016-03-18 14:15:33
    商业智能对于中小企业来说,由于其高昂的费用和运行维护技术水平要求高,往往难以承受,商业智能SAAS系统平台+模块的创新模式的出现能帮助中小企业走上商业智能之路。
  • 本课程将会以项目功能为驱动 以功能为载体依次从浅入深的讲解目前Java Web开发中使用的最新技术 课程中除了数据增删改查这种传统功能外 还涉及到权限设计 树形菜单 站内聊天 报表开发等实用的设计方法或技术实现 ...
  • 数据库基本概念

    千次阅读 2012-05-21 17:31:58
    数据库的基本概念 一、1、什么是数据库系统?它有什么特点? 数据、数据库、数据库管理系统与操作数据库的应用程序,加上支撑它们的硬件平台、软件平台和与数据库有关的人员构成了一个完整的数据库系统。 特点:...
  • Linux下USB core的工作原理及设备驱动技术 Linux下USB core的工作原理及设备驱动技术 Linux下USB core的工作原理及设备驱动技术 Linux以其稳定、高效、易定制、硬件支持广泛、源代码开放等特点,已在嵌入式领域...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 49,403
精华内容 19,761
关键字:

技术驱动型企业的概念