精华内容
下载资源
问答
  • 软件架构设计最佳实践

    千次阅读 2013-09-03 16:26:02
    软件架构设计最佳实践 课程介绍: 1、深入阐述软件架构设计的思想、方向及趋势;2、剖析软件架构的全景视图;3、结合实际案例分析架构设计过程及需求对架构的影响;4、如何实用设计模式来实现好的架构;5、实践...

    软件架构设计最佳实践

    课程介绍: 1、深入阐述软件架构设计的思想、方向及趋势;2、剖析软件架构的全景视图;3、结合实际案例分析架构设计过程及需求对架构的影响;4、如何实用设计模式来实现好的架构;5、实践分享多种类型架构设计的实现;6、SOA架构、企业集成系统架构、企业门户架构的设计实践;7、真实案例分析各行业软件架构实践。

    课程目标:1、掌握软件架构设计思想及本质;2、掌握软件架构建模,4+1视图,软件架构文档;3、软件架构的设计过程;4、熟悉软件架构设计模式;5、了解架构设计原则和方法学;6、掌握软件架构设计实现和企业架构应用实践;7、掌握架构设计问题的分析方法;

    课程大纲(3天):

    主题一:
    软件架构本质

    1.软件架构思想

    (1)软件架构诞生原因和定义
    (2)软件架构设计的任务,质量评价,特点
    (3)软件架构的主要理论、方向和趋势
    (4)Zachman架构框架, Meta Group/
    Open Group/Gartner企业架构
    (5)基于J2EE,.Net等技术架构概述

    2.软件架构的视图

    (1)软件架构视图的意义
    (2)4+1架构视图
    (3)逻辑视图 开发视图 物理视图 运行视图 场景视图
    (4)如何和怎样绘制软件架构视图
    (5)UML建模工具在架构视图的应用
    (6)结合多个案例,进行分析软件架构视图

    3.软件架构文档编写

    (1)软件架构文档的意义
    (2)ISO模板和RUP模板
    (3)软件架构文档的结构(避免出现不必要的重复和缺少关键信息)
    (4)从读者的角度编写软件架构文档
    (5)软件架构文档记录原理和如何避免歧义
    (6)文档的后期管理(使文档保持更新)
    (7)软件架构文档的评审
    (8)结合多个案例,进行分析和评价软件架构文档

    主题二:软件架构设计过程

    1.软件架构设计过程

    (1)软件架构设计过程方法论(应该有法可依)
    (2)确定关键需求
    (3)概念架构设计   
    (4)细化架构设计
    (5)软件架构的验证
    (6)结合具体案例进行分析,介绍当初项目架构设计的过程

    2. 需求决定架构

    (1)软件功能需求对架构的影响
    (2)软件质量需求对架构的影响
    (3)软件约束条件与架构的影响
    (4)结合多个案例,分析关键功能需求,质量属性需求,约束对架构的影响(项目错误的架构,导致不能最终验收)

    3. 概念架构设计

    (1)软件架构立方体图
    (2)软件架构模式和架构师经验的引入
    (3)使用目标-场景-决策表进行迭代架构设计
    (4)综合初步设计,确定高层分割
    (5)结合案例,进行分析该阶段的主要任务和相关成果,注意事项等

    4. 细化架构设计

    (1)根据功能确定职责模型
    (2)根据质量调整职责模型
    (3)基于接口确定职责间协作
    (4)完成4+1架构视图
    (5)完成架构文档
    (6)结合案例,进行细化架构的主要方法和成果,以及注意事项等

    5.架构设计的验证和评审

    (1)软件架构的验证
    (2)软件架构的验证方法和指标
    (3)软件架构的重构
    (4)软件架构的评审
    (5)软件架构的风险管理
    (6)结合案例,分析如何进行验证架构和架构设计的后期重构技巧

    主题三:软件架构设计原则与架构模式

    1.软件架构模式

    (1)软件架构模式概述
    (2)分层架构模式
    (3)Pipe/Filter Pattern
    4)MVC Pattern
    (5)Event-Based Pattern和Microkernel Pattern
    (6)其他模式的介绍
    (7)软件架构模式如何应用在实际项目
    (8)架构师实际项目架构经验总结和应用

    2.软件架构设计的方法论

    (1)什么是架构任务,如何分离关注点,它和系统是如何关联的
    (2)如何获得可维护性、可扩展性、可重用性、互操作性等
    (3)在系统中如何组织组件(Component)
    (4)如何组织组件(Component)的内部
    (5)如何保持平台相关的细节和应用的分离
    (6)如何应用封装(encapsulation)、抽象(abstraction)和 委派(delegation)的原则
    (7)如何应用设计模式来实现好的结构
    (8)如何使测试改进架构

    3.设计模式技术在软件架构设计之中的应用

    (1)面向对象软件架构设计思想
    (2)设计模式的本质论
    (3)分析创建型模式  
    (4)分析结构型模式
    (5)分析行为型模式
    (6)设计模式的在架构设计的综合应用
    (7)结合实际案例,分析设计模式在架构设计时期的应用

    4.软件架构之中应用框架(framework)

    (1)框架vs.类库
    (2)通用点vs.扩展点
    (3)设计模式技术在框架的设计之中的应用
    (4)如何开发框架  
    (5)如何选择第三方框架

    主题四:软件架构设计实现

    1.表现层框架设计

    (1)使用MVC模式设计表现层
    (2)BS和CS的选择
    (3)表现层中AJAX设计思想
    (4)表现层易用性的考虑
    (5)表现层的设计框架(Struts,JSF,WebWork,ASP.net,PHP等)
    (6)表现层的如何支持多渠道的接入(如支持Web,WAP等)
    (7)结合案例分析,表现层的架构设计

    2.业务逻辑层架构设计

    (1)业务逻辑层组件设计
    (2)业务逻辑层工作流设计
    (3)服务facade设计     
    (4)业务逻辑层实体设计
    (5)分布式应用场景
    (6)业务逻辑层框架(EJB,Springframework,.Net框架)
    (7)结合案例分析,业务逻辑层的架构设计

    3.数据访问层架构设计

    (1)数据访问层架构模式
    (2)数据访问层组件设计
    (3)离线和在线方式的数据访问
    (4)ORM、Hibernate,JPA与SQLMap(iBatis),LINQ设计思想
    (5)缓存技术在存取层的应用
    (6)数据访问层的性能考虑
    (7)事务管理和数据的同步与锁
    (8)连接对象管理设计
    (9)结合案例分析,数据访问层的架构设计

    4.领域模型设计,数据架构规划与数据库设计

    (1)领域模型设计 
    (2)数据库设计与类的设计融合
    (3)数据库设计与XML设计融合 
    (4)数据库性能规划

    5.通用服务层的架构设计

    (1)系统通用服务的架构设计
    (2)业务通用层的架构设计

    6.各层通信设计

    (1)应用通信的策略
    (2)进程之间和分布式通信
    (3)通信内容组织
    (4)同步、异步(基于Message的架构)

    主题五:企业应用系统架构设计

    1.SOA 面向服务的架构设计

    (1)掌握SOA的基本概念
    (2)了解服务的设计原则和方法学
    (3)SOA基础架构和企业服务总线ESB
    (4)服务识别,分类,实现
    (5)业务流程管理和BPEL技术
    (6)服务注册,发现,生命周期管理
    (7)服务的消息交换模式
    (8)服务的版本管理和SOA安全,性能管理
    (9)SOA的开发过程
    (10)SOA和组织,监管(SOA Organization and Governance)
    (11)SOA应用案例

    2. 企业集成系统架构设计

    (1)解决方案、数据集成、应用(接口)集成及应用服务
    (2)EAI参考模型:业务模式、概念模式、逻辑模式、物理模式和实现模式
    (3)如何设计企业应用系统集成
    (4)企业集成应用的架构模式
    (5)企业集成应用的案例分析

    3. 企业门户Portal系统架构设计

    (1)企业门户Portal概述
    (2)企业门户核心技术
    (3)企业门户内容管理(CMS)
    (4)企业门户的个性化
    (5)企业门户的架构案例

    主题六:软件架构设计专题技术问题分析

    1.软件架构设计专题技术问题分析

    (1)架构体系选择
    (2)架构设计中的数据库存取(ORM,底层存取,SQLMap等选择)
    (3)架构设计中的WEB容器、EJB容器及Spring等相关容器
    (4)软件架构设计的分布式和通讯的思考
    (5)软件架构设计的性能的思考
    (6)软件架构设计的可扩展性(集群技术)的思考
    (7)软件架构设计的事务管理的思考
    (8)软件架构设计的异常管理的思考
    (9)软件架构设计利用AOP和IOC这两个有价值的技术­­
    (10)软件架构设计的缓存技术的应用
    (11)软件架构设计的安全考虑
    (12)以上技术专题结合实际案例进行分析

    主题七:软件架构案例分析

    1.软件架构案例分析

    (1)电信行业软件架构案例研究
    (2)金融行业 软件架构案例研究
    (3)政府行业(社保和税务)软件架构案例研究
    (4)电力行业软件架构案例研究
    (5)SOA软件架构案例研究

     

     

    展开全文
  • 本文重点介绍了海尔电商平台的架构方案,也用不少篇幅阐述面临的场景和挑战,以及在架构方案决策过程中的关注点。其实作为一个优秀的电商平台,提供极致的用户体验、让技术最大化地创造价值,才是架构的终极目标。 ...
    本文重点介绍了海尔电商平台的架构方案,也用不少篇幅阐述面临的场景和挑战,以及在架构方案决策过程中的关注点。其实作为一个优秀的电商平台,提供极致的用户体验、让技术最大化地创造价值,才是架构的终极目标。

    多数电商平台都会经历相似的过程,流量和业绩每年以几倍至十几倍的速度增长,每年都要接受几次大规模、全方位的系统检阅,例如双11、周年庆等购物狂欢节,期间流量和订单可能是日常的十几倍甚至几十倍,产生的峰值对平台形成极其强烈的冲击,对电商平台的架构带来巨大的考验。因此,对电商平台的规划和架构工作不仅要高瞻远瞩,而且要细致入微,否则将导致平台无法满足高速增长的业务发展,细微处的失误也可能造成严重后果,不仅影响业务指标的实现,还可能导致对系统进行重新架构,劳时费力又伤钱。

    从2012年开始,海尔进入了网络化发展阶段,企业平台化、用户个性化和员工创客化的“三化”做法为电商的蓬勃发展提供了很好的土壤,也是海尔在面对互联网转型时的一个重点。海尔电商平台在发展过程中也同样经历了上述的问题。下面就抛砖引玉,为大家分享海尔电商平台应对电商峰值的架构设计经验。

    站在巨人肩膀上的SOA架构

    随着电商业务开展和业绩增长,系统结构和逻辑变得越来越复杂。为应对业务规模和复杂性的增长,需要将系统按照细分专业领域拆分;为应对流量和交易的增长,需要将网站进行大量子站拆分。这种状况下,SOA在保持清晰的系统结构和良好的逻辑组织方面提供了有力保障,为业务优化调整及新业务的开展带来巨大收益。

    通过服务封装和严格分离,为电商平台实现高伸缩性打下坚实基础。实现高伸缩性的主要工作集中在服务内部,对客户端影响的评估和改造工作也变得非常清晰。这将大大降低了实现高伸缩性的难度、工作量和实施周期。

    Dubbo是阿里提供的一个优秀的开源服务框架,在高并发情况下具有优秀的性能表现,海尔电商的SOA架构全面基于Dubbo服务框架。关于Dubbo框架的详细介绍可以参考GitHub上的Dubbo项目文档。下面对Dubbo框架工作机制进行简单介绍。

    如图1所示,每个服务提供者启动时都会注册到注册中心,并且通过长连接与注册中心保持心跳检测。这样注册中心就拥有一份完整、可用的服务提供者清单,某个服务提供者下线或由于故障中断,注册中心都能感知到并从清单中删除这个提供者。消费者启动时从注册中心获得服务提供者清单,并与提供者建立长连接,后续直接调用服务提供者,不再经过注册中心,避免注册中心成为瓶颈。每个消费者同样与注册中心保持长连接,这样有新的提供者注册或者某个提供者下线,都由注册中心通知到每个消费者。消费者在调用服务提供者时支持各种负载均衡和故障容错策略。监控中心则负责运行状态统计,例如每分钟的调用次数和平均耗时等。


    图1  Dubbo服务部署架构示意图

    Dubbo框架不仅实现了高性能、高可用性,而且使用方便,扩展性非常好。海尔电商所有服务都基于Dubbo框架开发,图2是系统整体SOA架构情况。


    图2  海尔电商SOA架构示意图

    鱼与熊掌兼得的产品服务架构

    面临的挑战

    产品的检索和展示在电商平台中具有举足轻重的地位,贯穿用户浏览、购物整个过程,以及订单交付全流程。产品服务需要为整个平台提供数据请求和检索服务,而各品类的产品差异性非常大,这给产品服务设计带来了巨大的挑战。

    • 负载权重高。电商平台中几乎每一个前台页面都与产品展示和检索相关,产品服务的负载在整个平台中占比非常高,对产品服务的请求量可能达到整站流量的几倍、几十倍。在电商活动高峰期间,核心系统中首当其冲的便是产品服务。因此,产品服务的设计必须满足高可用性,并且实现良好的性能和高伸缩性。
    • 产品差异性大。不同品类的产品具有不同维度的属性和规格参数,产品结构的设计必须具备足够的通用性和灵活性,才能良好地满足电商平台多品类运营的要求,以及在平台、品类扩展时可以提供快速的响应支持。
    • 全方位检索、排序。让用户方便快捷地在大量产品中找到自己满意的产品,是电商平台用户体验和信息架构中非常关键的一点。除了关键词搜索、按类目检索浏览之外,还需要提供按常用属性进行检索。在深入优化用户体验时,可能会提出更复杂的检索处理逻辑,例如组合属性检索,自动根据检索结果反过滤掉无结果的类目和属性,展示符合各个属性条件的商品个数,以及实时地结合大数据分析结果添加更多自动化、智能化的策略等。

    将页面或者部分页面的静态化是一种非常有效的优化方式,可以极大地降低对后台服务和数据的请求。但静态化带来的最大弊端就是服务端丧失了控制力,使得一些深入的自动化、智能化策略难以应用。因此,我们希望通过提升服务端的性能和伸缩性,来避免静态化的方案。

    性能和伸缩性是电商平台的关键指标。为了保障系统性能和伸缩性,不少时候我们需要牺牲或者完全拒绝某些功能,或者降低系统的灵活性和扩展性等。在产品服务架构设计阶段,我们努力思考和研究着一种可以鱼和熊掌兼得的解决方案。

    解决方案

    如图3所示,在数据库层允许复杂的产品存储结构设计,以细粒度、深度优化的关系模型充分实现产品数据模型的通用性、可扩展性。在数据模型设计时完全不用关心客户端检索查找的复杂性和性能问题。


    图3  产品服务逻辑架构示意图

    产品查询引擎将复杂的数据存储模型封装成一个简单的逻辑模型。这个逻辑模型实现的效果,完全等同于产品的所有属性都存储在同一张数据库表中,逻辑模型的每个属性对应数据库表中的一个字段。在这个逻辑模型的基础上实现了一个简洁的DSL,供客户端进行检索查询。客户端工作在逻辑模型和DSL之上,检索查询简单、灵活,同样完全不用关心产品数据存储模型的复杂性和性能问题。

    产品查询语言DSL

    产品查询语言DSL的语法类似SQL中的where条件语法,任何一个开发人员都很容易掌握。客户端将DSL表达式传给服务端,即可得到满足条件的产品列表及相关属性数据(图4)。


    图4  查询语言DSL工作原理

    DSL还支持中文语法,更方便使用,尤其对于业务人员进行复杂的后台检索查询,或者为前台页面及栏位设置产品展示的过滤条件等情况。


    产品查询引擎

    图5描述了查询引擎的核心组件及关键的执行流、数据流。编译器基于Antlr开发,职责是将DSL表达式编译为语法树,并完成一系列编译优化操作。执行引擎使用语法树逐个对产品进行匹配,得到符合条件的产品列表。智能排序引擎基于产品综合竞争力评估模型,为结果集进行排序,实现最大化提升转换率的目的。结果构造器则根据客户端在调用服务时指定的要求,将客户端所需属性加载到结果集中。


    图5  查询引擎工作机制

    在服务启动时将产品数据缓存到内存中,通过订阅MQ消息队列,在数据发生变化时刷新有变化的数据。

    产品服务架构

    产品服务分不同集群进行部署,面向Web应用和其他服务的集群在运行期间几乎不会产生数据库请求,因此不管网站访问量和交易量多高,数据库都不会产生压力瓶颈。在系统峰值期间,只需为Web和服务添加服务器即可,实现了高伸缩目标。

    效果

    • 性能:最高峰值2.6亿次/天,平均耗时60毫秒/次,后续对编译器和执行引擎进行优化,性能还有更大的提升空间。
    • 伸缩性:在一定条件下接近线性伸缩,所有使用产品服务的地方无须出于性能和系统压力原因额外设计其他方案,直接调用产品服务即可。
    • 通用性:不会因为电商平台性能和伸缩性要求而受到任何限制,可以像开发内部管理系统PDM一样设计产品数据模型,并且直接用于其他在线服务和前台Web应用,尽可能达到通用灵活的目的。
    • 扩展性:通过逻辑模型屏蔽了底层的数据模型,将数据模型的优化、扩展工作量以及影响范围降低到最小限度,提升了电商平台中产品服务的可维护性和扩展性。

    以查询引擎为核心的产品服务是一个鱼与熊掌兼得的架构设计案例,通用性、扩展性、伸缩性等在电商平台中相互制约、矛盾的一组核心架构目标全部得到满足。

    ……

    作者刘志斌,海尔电商首席架构师,资深技术控,10多年专注于供应链和电商领域,曾先后在麦考林和麦包包任职架构师。

    展开全文
  • 大多数的开发人员在讲DRY (Don't Repeat Yourself) 的时候大多认为...DYR更多的是一种架构设计思想,在软件开发过程中的万事万物均可能重复,大到标准、框架、开发流程;中到组件、接口;小到功能、代码均纯存在自我重
    
    大多数的开发人员在讲DRY (Don't Repeat Yourself) 的时候大多认为DRY是功能和代码的重复,也就是OAOO (Once And Only Once),其实不尽然。面向对象设计提倡的OAOO,强调的是利用面向对象的继承、组合等特性尽量让一个功能点只存在一个地方,所以OAOO强调的是面向对象设计,以及功能代码方面。而DYR的范围比OAOO要广泛得多。DYR更多的是一种架构设计思想,在软件开发过程中的万事万物均可能重复,大到标准、框架、开发流程;中到组件、接口;小到功能、代码均纯存在自我重复。而DYR提倡的就是在软件开发过程中应消除所有这些自我重复。

        在软件过程中的自我重复,总的来说有五种类型:

        (1) 一件事物,有多种的不同语言和方式来表达,不同的角色采用不同的语言去描述同一事物。在这些角色之间需要协同工作时造成的重复。

        比如,架构设计师用一种语言和方式描述其架构设计,可为PPT、Word文档、Visio、建模工具等。开发人员的工作语言则是程序代码。两种角色描述的是同一事物,只是描述语言不同而已,这样造成架构设计师的架构输出,不能作为开发人员的开发输入,而不能被开发人员重用,导致一定的自我重复。这就像一个人用英文写书,一个人用中文写书,内容类似,那么中文作者要么重新整理内容并书写书籍,要么就翻译英文书籍,不管哪种,造成重复工作劳动是在所难免。

        对于此类的自我重复,随着模型驱动的成熟和广泛应用将逐渐减少。模型驱动架构中业务建模、架构建模和程序编码等之间,通过Unified Modeling Language(UML)、the Meta-Object Facility (MOF)、XML Metadata Interchange (XMI)和自动化代码生成等语言、标准和技术进行互相转换,达到Don't Repeat Yourself。如下图所示:

        传统的开发过程中,需求、分析、设计、开发等各个阶段,可能采用不同的描述语言和方式,互相之间也较难转换,所以他们之间不能无缝的相互转换,造成了重复沟通、理解和建模。

        模型驱动开发,在开发过程的每个阶段基于标准和转换工具,所以每一个阶段的成果,都可以被下一个阶段复用,消除重复。这也是标准的魅力之一吧。

        (2) 同一件事物,不同的人各描述了该事物的不同方面,造成他们之间所描述的事物既类似又不同,有重复的地方,又不完全一样,导致自我重复。

        比如,银行中的用户信息模块,在"网上银行"、"公积金贷款",和"信用卡系统"中各自都可能有一个模块,从数据库、到逻辑、到界面都各自重复一套,他们之间既类似又有一些区别,如需要的信息不一样。导致这些模块之间的自我重复。

        对于此类的自我重复,是由架构设计导致,在架构设计阶段没有按照"组件化"、"服务化"和"层次化"的架构设计,造成在一个事物不能符合不同模块和系统的需求,并且无法扩展。

        这种自我重复,在企业的遗留系统和新系统之间尤为明显。因为大多企业的老系统在构建时由于技术、组织结构等原因,都是采用垂直的渠道架构,即存储层、逻辑层、展现层完全重新实现,甚至连技术框架都和其他渠道相异。如某银行业的多渠道应用中,不同渠道(如网上银行和手机银行)的逻辑类似,但在两个系统中重用性不高,存在着大量的自我重复。如下图左所示:

        随着SOA(Service Oriented Architecture)的广泛使用,再辅助以层次化架构,能有效解决此类问题。

        重复的组件要被重用,就需要是组件化的,并且能够被访问到。EJB、Web Service以及相应的组件化、基于服务的设计思想,一定程度解决了这些问题,缓和了在企业架构中的重用性问题。

        而层次化的架构设计则既是解决架构重复的途径,也是结果。层次化的架构演变过程,可以在人类社会发展过程中找到似曾相似的影子。在人类社会中,任何事情重复到一定程度,就会产生一个新的职业或阶层,比如,找房子的人多了,就自然会产生中介。在架构设计中也是一样。任何设计重复到一定程度,就应该抽象出新的层次。这个层次也许可以作为一个新的组件,也可能做出一个新的产品。

        上图2右边的架构,是银行多渠道整合的架构设计,是基于SOA架构的、多层次高度重用的架构设计,银行在新增一个渠道(如增加ATM渠道)时,能够重用大量的其他渠道的组件。


        (3) 没有自我重复,但重复别人。指一个功能有很好的免费开源框架或者标准可以依据,但设计开发时没有采用,而重新发明轮子,导致不能重用已有的标准或开源框架的优势。

        记得几年前参加的一个企业信息管理系统的产品开发,该产品从底层MVC框架开始开发,还开发了界面UI控件、自己的XML流程引擎实现等,然后才是在这个基础上开发该企业的信息管理系统。最后结果如何可想而知:投入产出比失衡,以失败告终。这是一个典型的"没有重复自己,但重复标准或免费成熟框架"的例子。

        在商业中的专业分工、竞争优势理论和软件架构思想有很多相通之处。一个开饭店的,不应该去种大米、白菜或养猪,而应该抓住自己的核心竞争优势,开好饭店。相同的,种菜的、养猪的,也不应该无缘无故跑去开饭店。除非他们各自都想转行,进入另外的专业化分工领域,同另外领域内公司竞争。

        在软件业中也是一样的道理,每个产品都有其核心竞争力,每个产品都应该把握住本产品的核心竞争力,并投入最大的人力物力去经营。而对于其它的标准、辅助工具、框架或产品等,应该持开放的态度,复用已有的标准、成熟框架或产品。当然,除非你想重新定位你的产品。

        这种类型的错误技术人员经常会犯,但作为产品的架构设计师,应该尽量杜绝这种错误的发生。

        (4) 开发过程中信息重复,如软件过程中用到的工具(项目管理系统、开发工具、测试计划及用例、Build工具、版本管理工具等)之间的信息重复;还有软件过程中各种角色的沟通重复,如开发人员报告进度给开发组长、开发组长又重新报告进度给项目经理等。如下图所示:

        对这一类型的自我重复,一个集成的协作平台能解决问题。基于这个协作平台,软件过程中所有角色、工具和流程都能无缝的协作,消除了信息重复和沟通重复,加快开发效率。如下图所示:所有的工具无缝集成,消除了信息重复;所有的角色都基于一个协作平台,能够实施反映产品的状态、信息、各种历史记录等,极大降低了沟通重复。

        (5) 缺乏重构导致自我重复。这一种自我重复是最幼稚且低级的重复,但在很多产品的代码和文档也大量存在。一个功能在不同模块中重复拷贝使用、对象继承和组合关系混乱、文档关系混乱等都属于这一类的问题。

        对于这一类型的自我重复,对软件进行持续重构是唯一的好方法。代码重构具体请参考《重构》这本书;至于文档重复,大家不妨把《重构》的思想应用于文档,也必有所得。

        总结

        Don't Repeat Yourself,是软件开发的最佳实践,良好的软件开发应该是非自我重复的,同样按照非自我重复思想设计开发的软件,往往是好的软件。

        · DRY,消除软件开发的各个阶段之间的重复,以客户和需求为中心,加快开发速度。

        · DRY,遵循"组件化"、"服务化"、"层次化"的架构设计,使得架构清晰,层次分明,并易于重用。

        · DRY,不自我重复,也不重复别人,特别是标准和成熟的开源框架,使得架构开放,稳定,并减少成本。

        · DRY,不重复信息,不重复沟通,改进管理流程,加快开发速度,达到有效沟通。

        · DRY,持续重构代码,文档等,保持软件简介、清晰,便于维护。

    展开全文
  • 2.3 系统架构设计 2.3.1 系统整体架构: 系统的总体架构分为以下几个部分: 1.接入层 接入层基于数据抽取转换存放平台,主要实现功能如下: (1)抽取:将数据从数据库或者外部文件读取出来,包括关系型数据库、半...

    一、券商实施个性化推荐项目的必要性

    1.1 个性化推荐技术发展背景

    目前,随着用户接收到的信息量爆炸般增长,传统的推荐以及服务方式的边际收益正在不断减少,用户个性化的需求变得越来越多。大数据实时个性化服务,主要基于大数据用户画像、产品画像建设成果,结合实时流计算框架,以客户需求为中心进行服务,做内容的主动创新和服务资源的精准配置,在恰当的时间将个性化的服务以合适的方式交付给需要的客户。目前涉猎到的应用包括实时热搜、市场热点、个性化资讯推荐和理财产品推荐,这部分的创新应用尝试主要基于人工智能算法实现。以个性化资讯推荐为例,主要利用在SPARK分布式集群上设计适合于证券金融资讯的协同过滤实时推荐算法,最终实现客户的个性化推荐。人工智能算法有效提升了用户体验和推荐内容的质量、精准度,可以为公司千万用户提供千人千面的全渠道优质服务。通过本行业推荐系统CTR(点击到达率)指标进行评估,个性化推荐可将券商互联网业务客户转化率提高三到五倍;可实现基于互联网的新增开户数、用户规模和用户活跃率的市场领先。

    二、证券行业个性化推荐系统方案设计

    2.1 设计目标

    利用大数据技术的应用,整合公司内外用户服务相关系统和数据,通过基于用户画像的建模方法,运用机器学习和数据建模技术,为用户提供个性化、定制化的金融和资讯产品。

    具体表现为:渠道互联网化、产品互联网化、平台互联网化三大体系,建设统一大数据处理平台作为支撑平台,形成一套互联网与大数据综合理论。以技术创新带动业务创新,提升公司差异化竞争力。其中渠道互联网化是本质是将互联网作为金融服务与最终用户之间进行交易的渠道。这种渠道既包括宣传渠道,交易渠道,也包括集成渠道和监管渠道。产品互联网化与渠道最大的区别是企业在互联网,而不是内部交付产品。即企业将产品相关的金融额度、服务、内容全部放到互联网上,并通过互联网和其它服务商进行集成。最终用户在互联网上完成产品和服务选择以及支付。企业内部只保留必要的核心交易记录和结算记录。平台互联网化,或者说互联网平台进入金融领域,是目前互联网金融探讨最热烈的切入点。既有的金融企业,希望通过平台互联网化,直接加载互联网相关的用户群,扩大金融市场,缩减金融成本,再通过个性化推荐等有效触达手段提升用户活跃度。

    2.2 负载均衡设计

    Netty数据接口服务使用反向代理实现负载均衡,进而达到高可用性。我们在不同服务器上布置了多个Netty数据接口服务,并使用F5制作了一个虚拟IP地址,作为Netty的反向代理地址,实现负载均衡。当某个Netty服务崩溃时,F5会自动屏蔽它的地址,不再将数据请求发送给它,保证数据接口的正常、稳定运行。

    2.3 系统架构设计

    2.3.1 系统整体架构:

    图片1.png

    系统的总体架构分为以下几个部分:
    1.接入层
    接入层基于数据抽取转换存放平台,主要实现功能如下:
    (1)抽取:将数据从数据库或者外部文件读取出来,包括关系型数据库、半结构化文件等。
    (2)清洗:将一些脏数据和不合规范的数据进行过滤转换使取符合规范。
    (3)转换:将数据进行数据类型改变,格式变换,数学计算,逻辑操作等。
    (4)过滤:按照特定的列的值进行提取数据。
    (5)关联:不同数据流按照特定的列进行合并成新的数据流。
    (6)去重:按照特定的列去掉重复数据。
    (7)排序:按照特定的列对数据流排序。
    (8)加载:把数据装入数据库或者文件中,以供后续使用。

    2.存储和与处理层
    存储和与处理层基于大数据处理和分析平台以及操作性存储和分析平台,其中大数据处理和分析平台主要实现功能如下:
    (1)原始数据存储:原始数据存储指从外部数据源获取的结构化和非结构化数据(日志文件、运营数据、业务数据等)的原始备份。
    (2)外部数据共享:外部数据共享存储指其他外围系统产生的日志数据或相关
    重要业务运营数据的共享存储区。
    (3)低密度数据沉淀:低密度数据沉淀类似于数据仓库概念中的数据沉淀层,其数据来源是经过清洗转换后的源数据层,按不同分析角度进行关联、统计、轻度汇总等实现的数据沉淀。
    (4)高密度数据汇总:高密度数据汇总类似于数据仓库概念中的数据集市的概念,将低密度沉淀的数据按照不同维度属性进行高密度汇总,比如 按渠道属性、按地域属性、按用户属性等进行统计汇总。
    (5)指标分析:KPI指标指关键业绩指标,是分析关键指标或重要指标的方法之一,其特点是考核指标围绕关键成果领域进行选取,通过建立评价指标体系、设定评价指标标准、展现关键指标结果、审核关键指标等来实现KPI指标的考察与跟踪。

    3.模型和分析层
    模型和分析层基于模型平台,主要实现功能如下:
    (1)统计模型:根据选定的数据源,经过统计、归并等数学过程,提取出有用的新数据。
    (2)分类模型:选取与待分类对象相关的数据,并基于这些数据,对目标对象进行等级(或者类别)划分。
    (3)预测模型:以预测目标对象在未来一定时间内的走势为目标,选取适当的相关数据源和预测方法,对目标对象的未来情况做出估计。
    (4)实时推荐架构:针对统计建模和个性化定制的推荐结果,建设实时推送的定制化平台基础构建。

    4.展现和应用层
    展现和应用层基于指标平台以及业务服务和展现平台,指标平台主要实现功能如下:
    (1)指标定义:定义系统使用的指标体系,定义指标的分级、分类,指标类型,指标单元,指标维度、精度,指标版本,指标实例,来源,状态和应用。
    (2)指标维护:通过管理流程来维护指标,包括指标申请,审核,录入,修改,生产和消亡。

    2.3.2 系统物理架构设计

    图片2.png

    物理架构由上图中的数据库集群、Hadoop集群、Kylin集群、Elasticsearch集群、对外接口服务器、大屏服务器、ETL服务器、任务调度服务器、Kafka集群、Spark Streaming集群、Redis集群、Netty服务器、报表服务器、界面数据接口服务器等部分组成。
    (1)当前部署10台列式数据库服务器集群,其中一台为master,其他为slave。
    (2)Hadoop集群由50台服务器组成,其中六台管理节点,其余为数据节点。包含Hadoop、Hbase、Hive、Spark、ZooKeeper等大数据生态环境的组件。
    (3)ElasticSearch集群是提供面向客户的在线查询及全文检索引擎,由8台服务器组成,每台服务器上部署有2个ElasticSearch实例,以充分发挥ElasticSearch的性能。集群配置有一个master实例,以及两个可以被选举为master的DataNode,提供高可用性。
    (4)任务调度服务器:负责数据工厂内部所有类型的任务调度服务器,包括2台配置数据库服务器,两台应用服务器,双机互备。
    (5)ETL服务器:数据采集服务器,一主一备。
    (6)Kylin集群:多维应用服务器,两台做负载均衡。
    (7)个性化推荐相关服务器集群:Kafka集群、Spark Streaming集群、Redis集群,各三台做分布式集群部署、Netty服务器两台做负载均衡
    (8)界面数据接口、对外数据接口服务器:两台做负载均衡

    2.3.3个性化资讯推荐模块逻辑架构设计

    图片3.png

    数据流过程
    (1)前端应用向总线发送获取咨讯的请求;
    (2)请求信息经总线到F5进行解析;
    (3)请求信息经F5到Netty进行解析;
    (4)经Netty在Redis中查询相关客户的咨讯ID;
    (5)返回这个客户的咨讯ID至Netty;
    (6)返回这个客户的咨讯ID至F5;
    (7)返回这个客户的咨讯ID至总线;
    (8)返回这个客户的咨讯ID至前端;
    (9)前端根据推荐ID列表,经总线发起咨讯内容请求;
    (10)请求到公共缓存;
    (11)公共缓存返回咨讯主题、常规信息、URL至总线;
    (12)总线将咨讯主题、常规信息、URL返回至前端;
    (13)前端根据URL通过公网访问CDN获取文件;
    (14)CDN返回咨讯带的文件,如图片等。

    工作流过程
    A. 实时数据获取:
    (1)将实时资讯内容通过Kafka推送给预处理模块;
    (2)将外部语义分析训练数据通过Kafka推送给语义分析模块。语义分析模块用外部训练数据优化其标签系统。

    B. 资讯预处理模块的数据交互:
    (1)资讯预处理模块对资讯内容进行清洗和预处理,调用语义分析模块的HTTP服务获取资讯内容的标签;预处理模块接收到资讯标签结果后,将结果结构化,其中需要的维度信息从对内Redis中获取;
    (2)将原始资讯信息存入ES;
    (3)将结构化的资讯标签结果存入Redis、Kafka和HBase,如下所示,
    i)Redis:更新Redis中资讯状态表,
    ii)Kafka:供Spark Streaming计算Item CF等资讯相关指标,
    iii)HBase:供推荐引擎离线训练推荐规则。

    C. 日志预处理模块的交互
    (1) Java批量的解析日志存入Hadoop,供推荐引擎离线训练推荐规则;
    (2) LogStash实时解析日志存入Redis和Kafka,如下所示,
    i)Redis:更新对内Redis中客户状态表,
    ii)Kafka:供Spark Streaming计算User CF等客户相关指标,以及统计热点资讯等信息。

    D. 推荐引擎中批量获取训练数据:
    (1)从Hadoop中获取用户点击行为历史数据;
    (2)从Hbase中获取资讯结构化标签历史数据。

    E. 推荐引擎与Spark Streaming交互:
    (1)推荐引擎根据用户行为历史数据、资讯标签历史数据以及CTR等评估指标,测试、调整、优化自定义推荐规则和基于机器学习的自动化推荐规则;
    (2)推荐引擎生成的推荐规则提供给Spark Streaming使用,推荐引擎与Spark Streaming无直接的数据交互。

    F. Spark Streaming根据实时数据流、缓存、规则(E)计算推荐列表:
    (1)资讯状态缓存,F3-用户状态缓存,两者保存在对内Redis中;
    (2)实时资讯流,F4-前端实时日志流,两者保存在Kafka中。

    G. Spark Streaming将推荐结果列表保存在对外Redis中。

    2.4 设备需求

    本项目所需要用到的设备层面的需求如下表所示:

    2.5 个性化推荐系统模块设计

    2.5.1 外部接口设计

    (1)资讯看了又看

    图片4.png

    (2)热点资讯

    图片5.png

    (3)个性化资讯推荐

    图片6.png

    2.5.2 内部接口设计

    (1)更新客户相关信息

    图片7.png

    (2)更新个股相关信息

    图片8.png

    (3)更新板块相关信息

    图片9.png

    (4)更新资讯相关信息

    图片10.png

    (5)资讯点击次数统计

    图片11.png

    (6)APP客户端点击资讯记录

    图片12.png

    (7)更新客户持仓相关信息

    图片13.png

    (8)更新用户自选股相关信息

    图片14.png

    (9)资讯相似度计算

    图片15.png

    三、项目实施经验

    3.1 项目周期

    根据项目整体规划和预期目标,项目整体建设周期分成以下几个阶段:
    (1)项目调研和规划设计:一个月;
    (2)项目的总体分析和设计,包括技术架构选型、软硬件部署:一个月;
    (3)主要技术平台搭建和测试:四个月;
    (4)主要功能开发;针对公司内部进行金融产品、资讯和服务的个性化定制开发工作:三个月
    (5)试运行,验收:一个月

    3.2 执行实施标准

    本次项目的开发始终就严格按照标准化要求,遵循公司信息系统采购、建设和质量评估标准。力求最终按照规范化的工作方法管理项目循环过程,始终把最终用户放在项目产品供应优化和质量控制的中心。针对项目建设过程中每个阶段的标准化管理情况,具体分析如下。
    (1)实施需求调研
    需求调研阶段的目的是:对现有业务和IT现状进行调查和初歩诊断,明确咨询与实施的目标与范围.根据现状制定具体的行动方案。
    (2)项目准备
    对项目实施范围内的业务进行深入全面的分析,澄清需求,评估各业务大致工作范围和工作量,并结合产品拟定项目应用方案,建立一套系统运行的良好制度。根据现状设计项目总体规划,让项目有章可循,总体控制。
    (3)项目建设
    项目建设主要包括两个阶段,一个是项目开发、一个是项目实施。
    项目开发阶段主是产品的生产,主要包括项目的开发、测试,使用手册,产品审核等。
    项目现场实施阶段主要是产品应用的建立,主要包括项目实施计划,硬件及支持平台采购、运行环境配备,项目产品现场安装、调试、系统权限分配、客户培训,项目试运行、项目的变更,问题的跟踪解决、产品完善等。
    (4)项目交付
    项目交付阶段主要是在保证项目良好运行的同时,支持辅助系统使用和对接方能够流畅正确和理解系统使用方式,并完成项目验收,生成相关验收报告和项目总结。
    (5)运行支持
    项目支持主要是对完成项目后续维护服务体系建立,以保证项目的持续性和完整性。

    3.3 人员配备

    (1)项目管理办公室PMO
    负责整个项目的协调工作,主要负责与上级主管部门、其它子平台进行协调,并负责本项目各子系统工程组和软件开发组的相互协调,确保工程按时、有序地进行。负责组织安排好各种例会,协调会并形成文档等记录。
    (2)项目经理
    项目经理是项目团队的领导者,他所肩负的责任就是领导团队准时、优质地完成全部工作。作为项目的指挥者,项目经理要担任的职责是对项目的计划、组织和控制。我公司将为本项目的实施配备具有IT项目管理工作资质和经历,具有完成类似项目的经验,主持过多项大型软件开发、系统集成项目的管理和实施,具备与上级领导、客户及属下进行交流的技巧,并具有丰富专题知识的项目经历,该人将在联合领导组的直接领导下,作为具体承担人和联络人与联合领导组保持联系。
    (3)系统开发人员
    应用软件系统开发组在组长的组织下,对服务系统的各个子系统进行详细需求分析及设计,确定业务流程,各子系统功能,应用软件系统总体结构以及模块之间的关系,定义各功能模块的借口、控制接口、反馈接口,确定系统数据结构,分析各子系统之间的关系,确定技术实现路线。设计工作完成后,软件开发人员负责设计各模块的内部细节,并制定测试计划,对集成测试和性能测试等工作作出规定与安排。
    针对本项目软件开发的复杂性,应用软件系统开发组应详细划分项目队伍组织结构,并合理的分配人员,同时明确每人的分工,制定进度安排,确保开发任务的可控性。
    (4)测试人员
    测试组负责软件、硬件的测试工作,负责制定测试计划、测试内容。负责对应用软件的模块测试、功能测试、性能测试、内存测试、稳定性测试、综合测试,整个系统安装、调试完毕后对系统进行总体测试,在项目进行中及时发现软、硬件设备出现的问题、故障,帮助开发、集成人员快速、准确地解决问题,确保软、硬件设备能够按时投入正常运行。
    (5)文档管理人员
    文档组负责管理由各组在实施和服务过程中所填写的各种记录文档和其它技术资料,包括电子文档和文字材料。如项目管理文档、实施计划、实施进度、系统应用设计文档、系统配置情况、系统运行和维护手册、测试文档、初步验收报告、用户意见反馈表、系统测试报告、试运行情况、反馈技术手册、验收报告、系统维护日志项目会议纪要、项目进度报告和分包商提交的各种文档等等。在项目进行的各个阶段督促相关人员按时完成各种文档,工程交付后负责所有技术、质量文件的整理归档。

     四、运维管理经验

    运营监控部分分为服务器状态监控、服务监控两个部分,以便于掌握服务器、服务、数据总线的实时状态,及时发现、解决潜在的问题。

    (1)服务器状态监控
    编写python脚本实时采集服务器的cpu、内存、磁盘io、网络io等信息,并发送给OpenTSDB时间序列数据库,OpenTSDB负责接收、存储、查询、分析接收到的数据。OpenTSDB是基于Hbase的时间序列数据库,可以用于存储海量的时间序列明细数据,同时,它还提供了一个功能强大的GUI,可以轻松定制监控图表,只需选择参数即可分析、对比监控数据。

    当发现CPU、内存等服务器容量达到预警值的时候(不同系统的服务器有不同的预警值),即可根据系统的特点添加服务器资源,以提高系统的容量。

    (2)服务监控
    服务监控方面,使用Ambari监控Hadoop、Spark、Hbase、Hive等Hadoop生态圈的组件。Ambari是应用最为广泛的Hadoop生态部署、管理、监控工具。监控内容包括这些服务的状态,以及HDFS的空间使用情况、Block的健康状态,YARN的资源使用、MapReduce Job历史及运行状态,Spark应用的状态等。

    ElasticSearch集群的监控由Marvel负责。Marvel是elastic官方的ElasticSearch监控工具,可以查看集群中各个节点的状态及cpu、磁盘、JVM Memory的使用情况,各个Index的shard在集群中各节点上的分布情况与状态。此外,还可以查看Elasticsearch的查询、写入速度及延时,以及Shard的活动情况。

    对于Kafka、Redis、Netty,列式数据库、ETL系统、调度平台等服务来说来说,我们自主开发了一个集数据采集、数据传输、数据展示于一体的监控系统,监控这些服务的运行状态、所在的服务器状况等信息。

    展开全文
  • 有幸请到BEA的架构设计师刘杰给公司做了一次为期2天的架构最佳实践培训。个人印象来说,这次培训含金量比较高,讲师有非常多年的实际架构设计经验,且目前一直在做架构。讲的东西都是贴切实际,带来很多经验,和一些...
  • App 后台架构设计方案 设计思想与最佳实践

    万次阅读 多人点赞 2017-01-09 09:16:18
    CSDN 2016博客之星评选结果公布 ...App 后台架构设计方案 设计思想与最佳实践 标签: App后台架构设计用户验证方案后台架构的演进架构 2017-01-08 16:10 245人阅读 评论(0) 收藏 举报
  • App 后端架构设计方案 设计思想与最佳实践 标签: App后台架构设计用户验证方案后台架构的演进架构 2017-01-08 16:10 10957人阅读 评论(3) 收藏 举报 版权声明:本文为博主原创文章,未经博主允许...
  • 如果你想成为一名专业的前端开发人员,一定会被本书中关于架构的真知灼见和最佳实践深深打动。”——AndiGutmans ,PHP创始人暨Zend技术公司CTO “本书循序渐进地讲述技术背后的最佳设计和实践,包括很多好的模式和...
  • 企业架构设计思路与实践经验谈

    千次阅读 2013-05-20 17:34:55
    读完了于海澜先生的《企业架构》一书,并回顾自己这几年所参与的企业架构工作的点滴,理论与实践交织,关于企业架构的认识又增进不少。因此写下此文,其一对自己的过往经历做一阶段总结,其二希望对同为从事企业架构...
  • 高性能的Multi-Tenant最佳实践此文选自《互联网时代的软件革命—SaaS架构设计》一书 杨康的销售和市场拓展能力还真不是盖的。侠客录CRM 的SaaS版本一经上线,迅速吸引了大批的中小企业客户。企业只须每人每月支付50...
  • 大数据架构最佳实践

    千次阅读 2019-05-02 12:32:18
    软件供应商的营销部门已经做好了让...显然,这个银弹(比喻大数据)让企业看到了数十亿美元的投资流入,但没有投资回报!这应该责怪谁?毕竟,企业不必公布其内部流程或项目。我对此有不同的看法,原因应该在于IT部...
  • 前两天看到网络某位大牛的一篇文章分析超融合市场,其中提到“超融合是从很大意义上将计算、存储、网络、安全等企业级IT基础设施有机融合在了一起,但不只是硬件架构上的融合。到目前为止,能完全有机融合这四大元素...
  • 中间件技术峰会分享 | 微服务架构上云最佳实践发表于 2017-08-07 | 作者 李颜良 | 分类于 分布式服务 | 摘要:7月27日,云栖社区、阿里中间件举办了首届阿里巴巴中间件技术峰会,揭秘阿里10年分布式技术干货。...
  • 不同种类的操作系统 , 应用软件,系统软件和应用基础结构相互交织,这便是IT企业的现状。SOA凭借其松耦合的特性,使得企业可以按照模块化的方式来添加新服务或更新...针对架构最佳实践可分为重用、数据管
  • 在BATJ等互联网大厂大肆推广中台建设成果的当下,各个行业的企业似乎都想做数字化转型,建设业务中台,但是中台到底是啥,需要我们提前了解和学习,本文是我学习张旭老师《数据中台架构企业数据化最佳实践》一书的...
  • Java EE设计模式 Spring企业级开发最佳实践第一章@(java读书笔记)Java EE设计模式 Spring企业级开发最佳实践 概要总结 本书内容这本书在讲什么 读书目标为什么要看这本书 本书对象哪些人适合看这本书 预备知识看懂这...
  • Redis 高可用架构最佳实践

    千次阅读 2017-08-13 21:33:16
    架构比较新,最佳实践较少 多键操作支持有限(驱动可以曲线救国) 为了性能提升,客户端需要缓存路由表信息 节点发现、reshard 操作不够自动化 7、Twemproxy ...
  • 基于AWS的云服务架构最佳实践

    万次阅读 2015-01-30 12:43:52
    近年来,对于打造高度可扩展的应用程序,软件架构师们挖掘了若干相关理念,并以最佳实践的方式加以实施。在今天的“信息时代”,这些理念更加适用于不断增长的数据集,不可预知的流量模式,以及快速响应时间的需求。...
  • “基于搭建微服务架构实践,作者总结出一套适用于现代化Web和云技术的实战经验,并从微服务领域的先行者(如Netflix、Soundcloud、谷歌、亚马逊、Spotify等)身上学到了很多经验。全文很长,建议收藏转发后阅读。 ...
  • 内容来自2015云栖大会·广东峰会·企业级互联网架构分会现场, 阿里巴巴中间件架构师团队钟华老师分享的干货, 内容比较充实,匆忙间只记录了部分内容, 需要手机拍下来的PPT请留邮箱。 一、尽可能拆分 ·更好的...
  • 软件架构最佳实践和案例分析

    千次阅读 2014-11-13 14:33:28
    架构设计师——也就成为软件系统的最高设计者。此课程就是为有志成为卓越架构师的人准备的培训课程。作为架构设计师,需要具备统观全局、分而治之的能力,从子系统的划分到组件的定义,从系统设计能力到沟通、协调...
  • 微服务架构深度解析与最佳实践

    千次阅读 2020-03-01 21:52:39
    微服务架构深度解析与最佳实践 微服务架构的概念,现在对于大家应该都不陌生,无论使用 Apache Dubbo、还是 Spring Cloud,都可以去尝试微服务,把复杂而庞大的业务系统拆分成一些更小粒度且独立部署的 Rest 服务。...
  • 架构设计 例子和实践

    千次阅读 2012-01-20 09:45:51
    系统设计说明书(架构、概要、详细)目录结构 虽然这些文档一般来说公司都是有模板的,但我写这些文档以来基本上是每写一次就把目录结构给改一次,应该说这是因为自己对这些文档的理解开始加深,慢慢的越来越明白这些...
  • RESTful API 设计最佳实践

    千次阅读 2016-05-01 09:30:02
    1. 背景REST(英文:Representational State Transfer,表述性状态转移)描述了一个架构样式的网络系统,比如 web 应用程序。 目前互联网上充斥着大量的关于RESTful API(为方便,下文中“RESTful API ”简写为“API...
  • 微信红包订单存储架构变迁的最佳实践 作者:莫晓东,微信支付高级DBA。擅长大规模MySQL数据库的架构、优化和高可用;目前专注于社交支付的存储层运维和架构优化。   责编:仲培艺,关注数据库领域,纠错、寻求...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 40,619
精华内容 16,247
关键字:

企业架构设计最佳实践