精华内容
下载资源
问答
  • 软件架构万字漫谈:业务架构、应用架构与云基础架构 本部分节选自《软件架构设计》 软件开发就是把一个复杂的问题分解为一系列简单的问题,再把一系列简单的解决方案组合成一个复杂的解决方案。而软件开发中最大的...

    软件架构万字漫谈:业务架构、应用架构与云基础架构

    软件架构万字漫谈:业务架构、应用架构与云基础架构

    本部分节选自《软件架构设计

    软件开发就是把一个复杂的问题分解为一系列简单的问题,再把一系列简单的解决方案组合成一个复杂的解决方案。而软件开发中最大的挑战,就是即能够快速高效地针对需求、环境的变化做出改变,也能够持续提供稳定、高可用的服务。而软件架构,就是软件系统的骨骼与框架。

    所谓架构,见仁见智,很难有一个明确或标准的定义;但架构并非镜花水月或阳春白雪,有系统的地方就需要架构,大到航空飞机,小到一个电商系统里面的一个功能组件,都需要设计和架构。抽象而言,架构就是对系统中的实体以及实体之间的关系所进行的抽象描述,是对物/信息的功能与形式元素之间的对应情况所做的分配,是对元素之间的关系以及元素同周边环境之间的关系所做的定义。架构能将目标系统按某个原则进行切分,切分的原则,是要便于不同的角色进行并行工作,结构良好的创造活动要优于毫无结构的创造活动。

    软件架构的核心价值,即是控制系统的复杂性,将核心业务逻辑和技术细节的分离与解耦。软件架构是系统的草图,它描述的对象是直接构成系统的抽象组件;各个组件之间的连接则明确和相对细致地描述组件之间的通信。在实现阶段,这些抽象组件被细化为实际的组件,比如具体某个类或者对象。在面向对象领域中,组件之间的连接通常用接口来实现。架构师的职责是努力训练自己的思维,用它去理解复杂的系统,通过合理的分解和抽象,理解并解析需求,创建有用的模型,确认、细化并扩展模型,管理架构;能够进行系统分解形成整体架构,能够正确的技术选型,能够制定技术规格说明并有效推动实施落地。

    软件架构分类

    在笔者的知识体系中,实际上将架构分为业务架构、应用架构、云基础架构这几大类,业务架构主要着眼于控制业务的复杂性,基础架构着眼于解决分布式系统中存在的一系列问题。无论何种架构,都希望能实现系统的可变的同时保障业务的高可用。另一个层面,根据企业中职责的划分,我们往往可以将软件架构,及关联的架构师划分为以下几类:

    • 业务架构/解决方案架构:核心是解决业务带来的系统复杂性,了解客户/业务方的痛点,项目定义,现有环境;梳理高阶需求和非功能性需求,进行问题域划分与领域建模等工作;沟通,方案建议,多次迭代,交付总体架构。

    • 应用架构:根据业务场景的需要,设计应用的层次结构,制定应用规范、定义接口和数据交互协议等。并尽量将应用的复杂度控制在一个可以接受的水平,从而在快速的支撑业务发展的同时,在保证系统的可用性和可维护性的同时,确保应用满足非功能属性要求(性能、安全、稳定性等)。

    • 数据架构:专注于构建数据中台,统一数据定义规范,标准化数据表达,形成有效易维护的数据资产。打造统一的大数据处理平台,包括数据可视化运营平台、数据共享平台、数据权限管理平台等。

    • 中间件架构:专注于中间件系统的构建,需要解决服务器负载,分布式服务的注册和发现,消息系统,缓存系统,分布式数据库等问题,同时架构师要在 CAP 之间进行权衡。

    • 运维架构:负责运维系统的规划、选型、部署上线,建立规范化的运维体系。

    • 物理架构:物理架构关注软件元件是如何放到硬件上的,专注于基础设施,某种软硬件体系,甚至云平台,包括机房搭建、网络拓扑结构,网络分流器、代理服务器、Web 服务器、应用服务器、报表服务器、整合服务器、存储服务器和主机等。

    架构模式与架构风格

    软件架构设计的一个核心问题是能否使用重复的架构模式,即能否达到架构级的软件重用。也就是说,能否在不同的软件系统中,使用同一架构。当我们讨论软件架构时,常常会提及软件架构模式(Architectural Pattern)与软件架构风格(Architectural Style)。

    软件架构模式往往会用于具体地解决某个具体的重复的架构问题,而架构风格则是对于某个具体的架构设计方案的命名。软件架构风格是描述某一特定应用领域中系统组织方式的惯用模式;架构风格反映了领域中众多系统所共有的结构和语义特性,并指导如何将各个模块和子系统有效组织成一个完整的系统。

    在笔者的系列文章中,CRUD、分层架构、六边形架构、洋葱架构、REST 以及 DDD,都算是架构风格;而 CQRS、EDA、UDLA、微服务等则被划分到架构模式中。

    系统复杂性的来源与应对

    在软件开发中,程序员往往能够脱离现实规律的束缚,创造出天马行空的世界,其也是最具有创造力的活动之一。编程唯一需要的是创造力思维和思维组织能力,这意味着在软件开发过程中最大限制是理解我们正在创建的对象。随着软件的演进,加入更多的功能点,系统变得越来越复杂:各个模块(Module)间存在着各种微妙的依赖关系。系统的复杂性随着时间积累,对于程序员来说,修改系统时考虑周全所有的的相关因素变得越来越困难。这就会使软件开放进度变缓慢,并且引入 Bug,而导致会进一步延缓开发进度,增加开发成本。在任何一个系统的生命周期中,复杂性不可避免会增加;系统越大,需要更多的人开发,管理系统复杂性的工作就越困难。

    Eric Evans 在 Domain‐Driven Design 一书中吐槽了所谓的意大利面式架构,即代码确实做了有用的事,但很难解释它是如何去执行的;他认为造成这种窘境的主要原因是,将领域问题的复杂度与技术细节的复杂度混合在了一起,最终导致整体复杂度的指数级增长。

    软件架构万字漫谈:业务架构、应用架构与云基础架构

    复杂性不是凭空而来,很多时候也不是刻意为之,这也就意味着复杂性的增加往往不会以我们的主观意志为转移。就像房间里的大象,我们无法逃避,也不能视而不见。复杂性的来源可能是:

    • 吸积与持续迭代:增量式设计意味着软件设计永不结束,设计在系统的生命周期中持续发生,程序员要时刻考虑设计问题。增量开发也意味着持续重构。一个系统的初始设计几乎从来都不是最好的方案。随着经验的增加,必然会发现更好的设计方案。

    • 交互且无扩展性设计:当吸积效应导致的大规模系统,结合了交互这个特性,会使技术系统更加复杂。一个技术系统除了作用于自身,还会与其它大量系统产生交互。比如下单购买一件商品,那么订单系统,商品系统,支付系统,物流系统,卡券系统就会交互协作。这样吸积的复杂性,由于交互特性的出现,会呈现几何级数上升。

    • 不合理的业务封装:不合理的业务封装是一个相对宽泛的概念,其具体的表现譬如面向过程而不是对象、分层不合理等。

    • 缺乏统一语言:典型的敏捷开发的结构,流水线上的各个角色往往会专注于自己负责的环节,精细化的分工也限制了每个角色的全局视角;虽然我们经常提倡所谓的主人翁意识,但是在落地时又很难去推进。

    • 缺乏约束与规范:在团队协作开发的背景下,缺少规范和约束会严重损害架构的一致性(Consistency),代码的可维护性将急剧下降。可能规范在实现层面就是命名、分包等不影响代码运行的小问题,但是千里之堤,溃于蚁穴,正是这些微末的不注意导致了整体复杂性的雪崩。

    复杂性的应对永远不会是一劳永逸,我们需要不断地推陈出新,是动态、渐进的重塑自己对软件系统的认识,不断认识问题和寻找更优解的持续迭代。第一个控制复杂性的途径是代码简单,意图清晰(Obvious)。例如: 减少特殊场景的处理,或变量命名一致性都能降低系统复杂性。另一种方式就是对复杂问题的抽象然后分而治之。

    领域驱动设计

    领域驱动设计

    本部分节选自《领域驱动设计

    DDD 领域驱动设计,起源于 2004 年著名建模专家 Eric Evans 发表的他最具影响力的著名书籍:《Domain-Driven Design – Tackling Complexity in the Heart of Software》,Eric Evans 在该书中只是提供了一套原始理论,并没有提供一套方法论,因此多年来对于 DDD 也是见仁见智。更早些时候 MartinFowler 曾经提出贫血模型与充血模型的概念,他认为我们大多数系统以 POJO 作为模型,只有普通的 getter、setter 方法,没有真正的行为,好像缺少血液的人,在 Evans 看来,DDD 中模型都是以充血形式存在,也就是说在 DDD 中,我们设计的模型不仅包含描述业务属性,还要包含能够描述动作的方法,不同的是,领域中一些概念不能用在模型对象,如仓储、工厂、服务等,如强加于模型中,将破坏模型的定义。

    领域驱动设计架构

    领域驱动设计的战略核心即是将问题域与应用架构相剥离,将业务语义显现化,把原先晦涩难懂的业务算法逻辑,通过领域对象(Domain Object),统一语言(Ubiquitous Language)转化为领域概念清晰的显性化表达出来。

    • 统一语言,软件的开发人员/使用人员都使用同一套语言,即对某个概念,名词的认知是统一的,建立清晰的业务模型,形成统一的业务语义。将模型作为语言的支柱。确保团队在内部的所有交流中,代码中,画图,写东西,特别是讲话的时候都要使用这种语言。例如账号,转账,透支策略,这些都是非常重要的领域概念,如果这些命名都和我们日常讨论以及 PRD 中的描述保持一致,将会极大提升代码的可读性,减少认知成本。。比如不再会有人在会议中对“工单”、“审核单”、“表单”而反复确认含义了,DDD 的模型建立不会被 DB 所绑架。

    • 面向领域,业务语义显性化,以领域去思考问题,而不是模块。将隐式的业务逻辑从一推 if-else 里面抽取出来,用通用语言去命名、去写代码、去扩展,让其变成显示概念;很多重要的业务概念,按照事务脚本的写法,其含义完全淹没在代码逻辑中没有突显出来。

    • 职责划分,根据实际业务合理划分模型,模型之间依赖结构和边界更加清晰,避免了混乱的依赖关系,进而增加可读性、可维护性;单一职责,模型只关注自身的本职工作,避免“越权”而导致混乱的调用关系。通过建模,更好的表达现实世界中的复杂业务,随着时间的发展,不断增加系统对实际业务的沉淀,也将更好的通过清晰的代码描述业务逻辑,模型的内聚增加了系统的高度模块化,提升代码的可重用性,对比传统三层模式中,很有可能大量重复的功能散落在各个 Service 内部。

    微服务与云原生架构

    本部分节选自《微服务与云原生

    服务衍化

    单体分层架构

    在 Web 应用程序发展的早期,大部分工程是将所有的服务端功能模块打包到单个巨石型(Monolith)应用中,譬如很多企业的 Java 应用程序打包为 war 包,最终会形成如下的架构:

    软件架构万字漫谈:业务架构、应用架构与云基础架构

    巨石型应用易于搭建开发环境、易于测试、易于部署;其缺陷也非常明显,无法进行局部改动与部署,编译时间过长,回归测试周期过长,开发效率降低等。集中式架构分为标准的三层:数据访问层、服务层和 Web 层。

    在 Web2.0 时代刚刚流行的时候,互联网应用与企业级应用并没有本质的区别,集中式架构分为标准的三层:数据访问层、服务层和 Web 层。

    • 数据访问层用于定义数据访问接口,实现对真实数据库的访问;
    • 服务层用于对应用业务逻辑进行处理;
    • Web 层用于处理异常、逻辑跳转控制、页面渲染模板等。

    SOA 面向服务架构

    SOA(Service-Oriented Architecture) 面向服务架构,是在互联网应用规模迅速增长,集中式架构已无法做到无限制地提升系统的吞吐量的背景下,产生的涉及模块化开发、分布式扩展部署等相对宽泛的概念。

    软件架构万字漫谈:业务架构、应用架构与云基础架构

    SOA 是一个组件模型,它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来。SOA 中的接口独立于实现服务的硬件平台、操作系统和编程语言,采用中立的方式进行定义。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。面向服务架构,它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。服务层是 SOA 的基础,可以直接被应用调用,从而有效控制系统中与软件代理交互的人为依赖性。

    实施 SOA 的关键目标是实现企业 IT 资产的最大化作用。要实现这一目标,就要在实施 SOA 的过程中牢记以下特征:可从企业外部访问、随时可用、粗粒度的服务接口分级、松散耦合、可重用的服务、服务接口设计管理、标准化的服务接口、支持各种消息模式、精确定义的服务契约。

    软件架构万字漫谈:业务架构、应用架构与云基础架构

    服务消费者(Service Consumer)可以通过发送消息来调用服务,这些消息由一个服务总线(Service Bus)转换后发送给适当的服务实现。这种服务架构可以提供一个业务规则引(Business Rules Engine),该引擎容许业务规则被合并在一个服务里或多个服务里。这种架构也提供了一个服务管理基础(Service Management Infrastructure),用来管理服务,类似审核,列表(billing),日志等功能。此外,该架构给企业提供了灵活的业务流程,更好地处理控制请求(Regulatory Requirement),例如 Sarbanes Oxley(SOX),并且可以在不影响其他服务的情况下更改某项服务。

    由于分布式系统十分复杂,因此产生了大量的用于简化分布式系统开发的分布式中间件和分布式数据库,服务化的架构设计理念也被越来越多的公司所认同。如下是 Dubbo 官方文档公布了一张有关 SOA 系统演化过程的图片:

    软件架构万字漫谈:业务架构、应用架构与云基础架构

    MSA 微服务架构

    微服务(Microservices Architecture Pattern)由 Martin Fowler 在 2014 年提出的,是希望将某个单一的单体应用,转化为多个可以独立运行、独立开发、独立部署、独立维护的服务或者应用的聚合,从而满足业务快速变化及分布式多团队并行开发的需求。如康威定律(Conway’s Law)所言,任何组织在设计一套系统(广义概念)时,所交付的设计方案在结构上都与该组织的通信结构保持一致,微服务与微前端不仅仅是技术架构的变化,还包含了组织方式、沟通方式的变化。

    软件架构万字漫谈:业务架构、应用架构与云基础架构

    对于微服务,不同背景的人也有不同的见解,对于熟悉 SOA 的开发者,微服务也可以认为是去除了 ESB 的 SOA 的一种实现方案;ESB 是 SOA 架构中的中心总线,设计图形应该是星形的,而微服务是去中心化的分布式软件架构。SOA 更多强调重用,而微服务偏向于重写。SOA 偏向水平服务,微服务偏向垂直服务;SOA 偏向自上而下的设计,微服务偏向自下而上的设计。

    软件架构万字漫谈:业务架构、应用架构与云基础架构

    微服务与微前端原理和软件工程,面向对象设计中的原理同样相通,都是遵循单一职责(Single Responsibility)、关注分离(Separation of Concerns)、模块化(Modularity)与分而治之(Divide & Conquer)等基本的原则。从巨石型应用到微服务的衍化也并非一蹴而就,如下图也演示了简单的渐进式替代过程:

    软件架构万字漫谈:业务架构、应用架构与云基础架构

    软件架构万字漫谈:业务架构、应用架构与云基础架构

    Cloud Native 云原生架构

    云原生是通过构建团队、文化和技术,利用自动化和架构来管理系统的复杂性和解放生产力。
    — Joe Beda,Heotio CTO,联合创始人

    软件架构万字漫谈:业务架构、应用架构与云基础架构

    Pivotal 是云原生应用的提出者,并推出了 Pivotal Cloud Foundry 云原生应用平台和 Spring 开源 Java 开发框架,成为云原生应用架构中先驱者和探路者。早在 2015 年 Pivotal 公司的 Matt Stine 写了一本叫做迁移到云原生应用架构的小册子,其中探讨了云原生应用架构的几个主要特征:符合 12 Factors 应用、面向微服务架构、自服务敏捷架构、基于 API 的协作以及抗脆弱性。2015 年 Google 主导成立了云原生计算基金会(CNCF),起初 CNCF 对云原生(Cloud Native)的定义包含以下三个方面:应用容器化、面向微服务架构、应用支持容器的编排调度。

    软件架构万字漫谈:业务架构、应用架构与云基础架构

    云原生应用程序简单地定义为从头开始为云计算架构而构建应用程序;这意味着,如果我们将应用程序设计为预期将部署在分布式、可扩展的基础架构上,我们的应用程序就是云原生的。随着公共云将承载越来越多的算力,未来云计算将是主流的 IT 能力交付方式,CNCF 也对云原生进行了重新定义:云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中,构建和运行可弹性扩展的应用;云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API。

    • Codeless 对应的是服务开发,实现了源代码托管,你只需要关注你的代码实现,而不需要关心你的代码在哪,因为在整个开发过程中你都不会感受到代码库和代码分支的存在。

    • Applicationless 对应的是服务发布,在服务化框架下,你的服务发布不再需要申请应用,也不需要关注你的应用在哪。

    • Serverless 对应的则是服务运维,有了 Serverless 化能力,你不再需要关注你的机器资源,Servlerless 会帮你搞定机器资源的弹性扩缩容

    这些技术组合搭配,能够构建容错性好、易于管理和便于观察的松耦合系统;再结合可靠的自动化手段,云原生技术能够使工程师轻松地对系统作出频繁和可预测的重大变更。由此可见,云原生是保障系统能力灵动性地有效抓手;云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中,构建和运行可弹性扩展的应用。微服务架构非常适合云原生应用程序;但是,云原生同样存在着一定的限制,如果你的云原生应用程序部署在 AWS 等公有云上,则云原生 API 不是跨云平台的。

    软件架构万字漫谈:业务架构、应用架构与云基础架构

    云原生应用的关键属性包括了:使用轻量级的容器打包、使用最合适的语言和框架开发、以松耦合的微服务方式设计、以 API 为中心的交互和协作、无状态和有状态服务在架构上界限清晰、不依赖于底层操作系统和服务器、部署在自服务、弹性的云基础设施上、通过敏捷的 DevOps 流程管理、自动化能力、通过定义和策略驱动的资源分配。云原生是分布式应用当下重要的发展路径,其终态应当是 Distributionless,所有与分布式相关的问题由云平台解,分布式应用的开发会跟传统应用的开发一样方便,甚至更加便捷。

    云基础架构

    本部分节选自《分布式基础架构之虚拟化与编排

    应用基础架构变迁

    虚拟机

    虚拟机由某些特定的硬件和内核虚拟化组成,运行客户操作系统。称为管理程序的软件创建虚拟化硬件,其可以包括虚拟磁盘,虚拟网络接口,虚拟 CPU 等。虚拟机还包括可以与此虚拟硬件通信的宾客内核。管理程序可以托管,这意味着它是一些在主机操作系统(MacOS)上运行的软件,如示例中所示。它也可以是裸机,直接在机器硬件上运行(替换你的操作系统)。无论哪种方式,管理程序方法都被认为是重量级的,因为它需要虚拟化多个部分(如果不是全部硬件和内核)。

    软件架构万字漫谈:业务架构、应用架构与云基础架构

    VM 需要硬件虚拟化才能实现机器级隔离,而容器则只需要在同一操作系统内进行隔离操作。 随着隔离空间数量的增加,开销差异变得非常明显。

    容器

    在过去几年里,云平台发展迅速,但其中困扰运维工程师最多的,是需要为各种迥异的开发语言安装相应的运行时环境。虽然自动化运维工具可以降低环境搭建的复杂度,但仍然不能从根本上解决环境的问题。

    软件架构万字漫谈:业务架构、应用架构与云基础架构

    Docker 的出现成为了软件开发行业新的分水岭,容器技术的成熟也标志着技术新纪元的开启。Docker 提供了让开发工程师可以将应用和依赖封装到一个可移植的容器中的能力,这项举措使得 Docker 大有席卷整个软件行业并且进而改变行业游戏规则的趋势,这像极了当年智能手机刚出现时的场景——改变了整个手机行业的游戏规则。Docker 通过集装箱式的封装方式,让开发工程师和运维工程师都能够以 Docker 所提供的镜像分发的标准化方式发布应用,使得异构语言不再是捆绑团队的枷锁。

    软件架构万字漫谈:业务架构、应用架构与云基础架构

    容器是包含应用程序代码,配置和依赖关系的软件包,可提供运营效率和生产力。容器为我们提供了可预测的,可重复的和不可变的运行预期,容器的兴起是 DevOps 即服务的一个巨大推动因素,可以克服当今面临的最大安全障碍。容器化通过在操作系统级别进行虚拟化来使应用程序可移植,从而创建基于内核的隔离的封装系统。容器化的应用程序可以放在任何地方,无需依赖项运行或需要整个 VM,从而消除了依赖关系。

    作为独立的单元,容器能够在任何主机操作系统,CentOS,Ubuntu,MacOS,甚至是像 Windows 这样的非 UNIX 系统中运行。容器还充当标准化的工作或计算单元。一个常见的范例是每个容器运行单个 Web 服务器,数据库的单个分片或单个 Spark 工作程序等,只需要扩展容器的数量就能够便捷地扩展应用。每个容器都有一个固定的资源配置(CPU,RAM,线程数等),并且扩展应用程序需要只扩展容器的数量而不是单个资源原语。当应用程序需要按比例放大或缩小时,这为工程师提供了更容易的抽象。容器也是实现微服务架构的一个很好的工具,每个微服务只是一组协作容器。例如,可以使用单个主容器和多个从容器来实现 Redis 微服务。

    Kubernetes 与编排

    随着虚拟化技术的成熟和分布式架构的普及,用来部署、管理和运行应用的云平台被越来越多地提及。IaaS、PaaS 和 SaaS 是云计算的三种基本服务类型,分别表示关注硬件基础设施的基础设施即服务、关注软件和中间件平台的平台即服务,以及关注业务应用的软件即服务。容器的出现,使原有的基于虚拟机的云主机应用,彻底转变为更加灵活和轻量的容器与编排调度的云平台应用。

    软件架构万字漫谈:业务架构、应用架构与云基础架构

    然而容器单元越来越散落使得管理成本逐渐上升,大家对容器编排工具的需求前所未有的强烈,Kubernetes、Mesos、Swarm 等为云原生应用提供了强有力的编排和调度能力,它们是云平台上的分布式操作系统。容器编排是通常可以部署多个容器以通过自动化实现应用程序的过程。像 Kubernetes 和 Docker Swarm 这样的容器管理和容器编排引擎,使用户能够指导容器部署并自动执行更新,运行状况监视和故障转移过程。

    Kubernetes 是目前世界范围内关注度最高的开源项目,它是一个出色的容器编排系统,用于提供一站式服务。Kubernetes 出身于互联网行业巨头 Google,它借鉴了由上百位工程师花费十多年时间打造的 Borg 系统的理念,安装极其简易,网络层对接方式十分灵活。Kubernetes 和 Mesos 的出色表现给行业中各类工程师的工作模式带来了颠覆性的改变。他们再也不用关注每一台服务器,当服务器出现问题时,只要将其换掉即可。业务开发工程师不必再过分关注非功能需求,只需专注自己的业务领域即可。而中间件开发工程师则需要开发出健壮的云原生中间件,用来连接业务应用与云平台。

    Kubernetes、Service Mesh 和 Serverless 三者共同演绎不同层次的封装和向上屏蔽下面的细节。Kubernetes 引入了不同的设计模式,实现对各种云资源全新、有效和优雅的抽象和管理模式,让集群的管理和应用发布变成了件相当轻松且不易出错的事。被广泛采用的微服务软件架构将分布式应用的各种复杂度迁移到了服务之间,如何通过全局一致、体系化、规范化和无侵入的手段进行治理就变成了微服务软件架构下至关重要的内容。Kubernetes 细化的应用程序的分解粒度,同时将服务发现、配置管理、负载均衡和健康检查等作为基础设施的功能,简化了应用程序的开发。而 Kubernetes 这种声明式配置尤其适合 CI/CD 流程,况且现在还有如 Helm、Draft、Spinnaker、Skaffold 等开源工具可以帮助我们发布 Kuberentes 应用。

    软件架构万字漫谈:业务架构、应用架构与云基础架构

    Service Mesh 通过将各服务所共用和与环境相关的内容剥离到部署于每个服务边上的 Sidecar 进程而轻松地做到了。这一剥离动作使得服务与平台能充分解耦而方便各自演进与发展,也使得服务变轻而有助于改善服务启停的及时性。Service Mesh 因为将那些服务治理相关的逻辑剥离到了 Sidecar 中且作为独立进程,所以 Sidecar 所实现的功能天然地支持多语言,为上面的服务采用多语言开发创造了更为有利的条件。通过 Service Mesh 对整个网络的服务流量进行技术收口,让异地多活这样涉及流量调度的系统工程实现起来更加优雅、简洁与有效,也能更加方便地实现服务版本升级时的灰度、回滚而改善安全生产质量。由于技术收口,给服务流量的治理和演进、排错、日志采集的经济性等疑难问题创造了新的发展空间。

    延伸阅读

    软件架构万字漫谈:业务架构、应用架构与云基础架构

    您可以通过以下导航来在 Gitbook 中阅读笔者的系列文章,涵盖了技术资料归纳、编程语言与理论、Web 与大前端、服务端开发与基础架构、云计算与大数据、数据科学与人工智能、产品设计等多个领域:

    此外,你还可前往 xCompass 交互式地检索、查找需要的文章/链接/书籍/课程;或者在 MATRIX 文章与代码索引矩阵中查看文章与项目源代码等更详细的目录导航信息。最后,你也可以关注微信公众号:『某熊的技术之路』以获取最新资讯。

    展开全文
  • 软件架构经典书籍

    千次阅读 2011-06-25 13:28:00
    1.软件架构设计 作者: 温昱 内容简介:本书紧紧围绕“软件架构设计”这一主题,立足实践解析了软件架构的概念、阐述了切实可行的软件架构设计方法、提供了可操作性极强的完整的架构设计过程。另外,本书从思维...

    1.软件架构设计
    作者: 温昱
    内容简介:本书紧紧围绕“软件架构设计”这一主题,立足实践解析了软件架构的概念、阐述了切实可行的软件架构设计方法、提供了可操作性极强的完整的架构设计过程。另外,本书从思维方式的突破、面向对象设计、UML建模、过程与管理等关键过渡环节,为广大程序员的成长提供了切中肯綮的指导。本书可作为计算机软件专业本科生、研究生和软件工程硕士的软件架构设计教材,也可作为软件开发高级培训、软件开发管理培训的培训教材,更是第一线高级开发人员和开发管理人员的必备参考书。
    作译者介绍
    温昱,资深咨询顾问,CSAI特聘高级顾问,软件架构专家,软件架构思想的传播者和积极推动者。十年系统规划、架构设计和研发管理经验,在金融、航空、多媒体、网络管理、中间件平台等领域负责和参与多个大型系统的规划、设计、开发与管理。在《程序员》杂志、IBM DeveloperWorks等媒体发表了《图论思想与UML应用》、《敏捷设计从理论到实践》、《随需而变的RUP》等文章数十篇。译著有《应用框架的设计与实现——NET平台》等。
    作者: 温昱
    温昱 资深咨询顾问,CSAI特聘高级顾问,软件架构专家。软件架构思想的传播者和积极推动者,中国软件技术大会杰出贡献专家。千年系统规划、架构设计和研发管理经验,在金融、航空、多媒体、电信、中间件平台等领域负责和参与多个大型系统的规划、设计、开发与管理。作为资深咨询顾问,已为众多知名企业提供了卓有成效的架构培训与咨询服务。
    同作者作品
    软件架构设计(09年度畅销榜TOP50)
    SQL语言艺术 (china-pub首发) (08年度畅销榜TOP50)
    一线架构师实践指南(中大型系统架构设计指南)
    2. 架构实战—软件架构设计的过程
    原书名: The Process of Software Architecting
    作者: (英)Peter EelesPeter    Peter Cripps   
    译者: 蔡黄辉 马文涛
    内容简介:本书从基本原理入手,介绍软件架构设计过程中涉及的一些概念、流程、方法、用到的工作产品及可重用的资源,从第6章开始,通过介绍一个具体的案例来阐述如何定义需求、创建逻辑架构、创建物理架构。在第10章“进阶”中,作者补充说明了架构师和软件开发项目其他方面的关系,后面又说明了各种软件开发项目可能存在的困难及相应的处理方法。
    本书理论结合实践,介绍了一些可以应用到整个或部分的架构设计流程中的最佳方法。不管你是一位资深的架构师还是一位有志于成为架构师的初级使用者,通过阅读本书都能从中获益。
    作译者介绍
    Peter Eeles 是IBM的高级IT架构师,他就职于IBM的Rational品牌软件组。在这个职位上,他帮助组织提高软件开发能力,尤其关注和致力于改进架构流程。Peter从1985年开始从事软件行业,其主要工作是进行架构设计和实现大规模、分布式的系统。Peter是《Building J2EE Applications with the Rational Unified Process》(Addison?Wesley,2002)和《Building business Objects》(John Wiley & Sons,1998)的合著者。他还是英国计算机协会高级会员(FBCS)、工程技术协会(FIET)会员、IBM技术人员、Open Group
    3. 面向模式的软件架构.第4卷,分布式计算的模式语言(经典POSA系列的第4卷)
    原书名: Pattern-Oriented Software Architecture Volume 4: A Pattern Language for Distributed Computing
    作者: (德)Frank Buschmann    (英) Kevlin Henney    (美)Douglas C. Schmidt  
    译者: 肖鹏 陈立
    内容简介:本书关注分布式计算系统软件的设计和实现。书中首先介绍理解本书内容所需的核心的模式概念,分布式计算的好处和挑战;然后描述如何使用分布式计算模式语言,设计真实世界中仓库管理流程控制系统;最后重点讲述分布式计算模式语言,该语言陈述了创建分布式系统相关的技术主题。
    作译者介绍
    Fralk Buschmann是德国慕尼黑西门子技术公司的高级总工程师。他的研究领域包括对象技术、软件架构、产品线、模型驱动软件开发和模式。他在该领域著作甚多,其中最引人注目的便是POSA系列的前两卷[POSA1][POSA2]和最近的两卷:本书和[POSA5]。Frank在1992年至1996年曾是ANSIC++标准化委员会X3J16的成员,于1996年发起了首届EuroPLoP会议,与人合作汇编了数本模式方面的书籍[PLoPD3][SFHBS06],现任Wiley软件设计模式丛书的主编。
    译者: 肖鹏
    肖鹏,ThoughtWorks高级咨询师,敏捷过程教练,面向对象分析和面向对象设计专家。拥有6年以上软件开发实践经验,多次担任国内大中型企业敏捷流程改进、面向对象分析和面向对象设计咨询和培训。他长期关注于设计模式、架构模式、敏捷软件开发等领域,并致力于软件开发最佳实践的推广和应用。
    同作者作品
    Visual Studio 2005技术大全(使.NET程序员事半功倍的利器)
    Visual Studio 技术大全(微软技术大师力作)
    面向模式的软件架构.第4卷,分布式计算的模式语言(经典POSA系列的第4卷)
    4. 互联网时代的软件革命--SaaS架构设计
    作者: 叶伟   
    内容简介:本书是国内第一本完整介绍saas应用开发的书籍,聚集于架构设计。内容是互联网领域具有丰富实践经验的8位一线架构师,对于多年saas实践经验的总结。对于saas领域的业务、设计、开发人员,具有很高的指导价值。
    本书首先从saas的商业价值分析开始,讨论saas应用与其它应用最大的差异特征:多租户。saas应用架构是否成熟正是对多租户的三个重要特性的衡量:高性能、可配置性和伸缩性。本书将对saas应用成熟度的4个模型一一描述,并通过郭靖和杨康两个大学生的创业故事来描述saas应用逐步成熟到百万级以上租户时,应用软件的架构设计演变过程。
    同时,本书针对云计算、openapi、离线应用、安全以及开放平台等saas等相关的主题进行了深入的阐述。
    作者: 叶伟
    叶伟,阿里软件研发中心总监。曾先后就职于金仕达卫宁、IBM、金蝶,在HIS、ERP、SaaS领域领导开发了多个大型成功产品。复旦大学计算机科学学士、硕士,1993年获高级程序员,2000年被评为高级工程师。15年软件开发经验,专长面向对象分析&设计,以及SaaS应用架构设计。
    同作者作品
    互联网时代的软件革命--SaaS架构设计(SD大会现场签售全国独家首发)(09年度畅销榜TOP50)
    作者: 赵进
    赵进,阿里软件首席架构师,在管理软件领域和SaaS领域都有多年的开发和架构设计经验。现负责阿里巴巴软件互联平台的技术规划和架构设计工作,对于云计算、PaaS、OpenAPI、MultiTenant架构、SOA、MDA等领域都具有浓厚的兴趣。
    作者: 叶军
    叶军,计算机博士,阿里软件架构师。10年Web应用开发经验,对网站设计和互联网前沿技术有广泛的研究。现负责阿里软件互联平台的系统架构设计。
    作者: 闻波
    闻波,阿里软件桌面平台架构师。一直致力于Windows应用软件开发,对面向对象程序设计和Windows系统底层的研究有丰富的经验;对驱动程序开发、软件加密/解密等有较深入的研究。
    黄晓龙,阿里软件高级架构师,先后在金蝶、腾讯等多家著名IT公司任职,在企业管理软件、架构设计、OOAD、敏捷开发、项目管理等方面积累了多年经验。
    龙良,阿里软件架构师,先后在金蝶、中兴等多家著名IT公司担任架构师。系统分析师(2005年),清华大学软件工程硕士。在Web架构设计和企业管理软件等方面积累了多年经验。
    作者: 曾义
    曾义,阿里软件Web平台技术经理,四川大学计算机科学硕士。专长于MDA、Web前端组件设计、SOA,目前领导SaaS应用开发平台XPlatform的研发
    作者: 李战
    李战,阿里软件架构师,从事SaaS研究多年。在SaaS数据库、Web架构、前端框架以及数据库全文检索方面都有丰富的经验。
    作者: 莫建祥
    莫建祥,阿里软件高级架构师。擅长大规模即时通信系统、分布式存储和数据库系统、分布式计算、高性能计算、网络通信的设计开发。现负责阿里旺旺(IM产品)的整体架构设计。
    5. 企业应用架构模式(英文影印版)(企业应用开发圣经)
    原书名: Patterns of Enterprise Application Architecture
    作者: (美)Martin Fowler  
    内容简介:面向对象大师martin fowler及其专家级合作者将40多种常用解决方案转化成模式,为我们提供了这本能够应用于任何一种企业应用平台的、关于解决方案的参考书。本书叙述深入浅出,采用大量uml 图进一步阐明有关概念。前面介绍企业应用的背景知识,如分层架构、web表现、业务逻辑、数据库映射、并发、会话、分布策略等。在此基础上,随后的各章分别对与这些背景知识相关的设计模式进行了详细的介绍,并配以详细的java代码或c#代码示例。.
    本书适合设计和构建企业应用的软件架构师、设计人员和编程人员阅读,同时也可作为高等院校计算机专业及软件学院相关课程的参考教材。..
    随着信息技术的广泛应用,系统需要处理的数据量越来越大,企业级软件开发已经渐成主流,而开发人员面临的困难与挑战也是显而易见的。更糟糕的是,这一领域的资料一直非常缺乏。
    本书是软件开发大师martin fowler的代表作,采用模式的形式系统总结了业界多年积累的经验,被称为“企业级应用开发领域的圣经”,出版以来一直畅销不衰,至今仍然无可替代。作者在精彩地阐述了企业应用开发和设计中的核心原则基础上,详细、生动地讲述了51个模式并给出主流平台(java和.net)中的应用实例,更分析了许多相似模式之间的差异,提供了具体运用和选择这些模式的大量经验之谈,使你不仅知其然,更知其所以然。
    这是一部软件开发领域不朽的经典,任何一位真正的软件开发人员都不可错过。...
    作译者介绍
    Martin Fowler 享誉世界的软件开发大师,现为著名软件开发咨询公司ThoughtWorks的首席科学家。他在面向对象分析与设计、UML、设计模式、软件开发方法学、 XP、重构等方面都有重要贡献。他更是全球最具影响力的技术作家之一,除本书外,他的《分析模式》、《UML精粹》、《重构》等著作都已经成为经典。
    作者: Martin Fowler
    Martin Fowler是一位独立咨询顾问,他运用对象技术解决企业问题已经超过十年。他的顾问领域包括健康管理、金融贸易,以及法人财务。他的客户包括Chrysler,Citibank,UK National Health Service,AndersenConsulting,NetscapeCommunications。此外Fowler也是objects、UML、patterns技术的一位合格讲师,他是《AnalysisPatterns》和《UML Distilled》的作者。
    同作者作品
    企业应用架构模式
    UML精粹:标准对象语言简明指南(第3版)
    UML精粹:标准对象建模语言简明指南(第3版)(英文影印版)
    6. .NET软件架构之美(英文影印版)(.NET软件架构设计圣经)
    原书名: Microsoft .NET: Architecting Applications for the Enterprise
    作者: (意)Dino Esposito    Andrea Saltarello
    内容简介:软件架构设计是现代软件开发的核心,它不仅是一门技术,更是一门艺术。然而,长期以来,一直没有一本讲述.net架构设计的书。.
    本书填补了这一缺憾。两位作者人选可谓众望所归,他们将gof设计模式、martin fowler企业架构模式、eric evans领域驱动设计等业界精华与自己多年软件开发实战经验结合起来,深刻阐述了软件架构设计思想精髓。作者还从技术架构角度逐章讲述了业务层、服务层、数据访问层和表现层的分层设计,同时介绍了各种软件架构设计方案的优与劣,如何在各种方案中做出抉择,以及如何将这些设计原则更具体地应用到应用程序中。..
    本书出自两位具有多年软件开发经验的 asp .net专家、作者和培训师之手,内容涉及多层架构、设计模式以及设计原则。第一部分简要介绍 uml、设计原则及模式;第二部分从技术架构角度讨论分层设计。本书行文流畅,语言通俗易懂,阐述了各种架构设计技术方案的优与劣,并讲述了如何在优与劣中做出权衡。中设计了真实的场景,展示了如何将这些设计原则更加具体地应用到 .net应用程序中。
    本书适合各层次 .net开发人员阅读。...
    作译者介绍
    Dino Esposito .NET和软件架构技术方面的世界权威,微软ASP.NET MVP。目前就职于著名的.NET技术咨询公司IDesign。他是广受欢迎的技术作家,担任MSDN Magazine特邀专栏作家多年,并撰有Programming ASP.NET 3.5 Core References等名著。.
    Andrea Saltarello 微软ASP.NET MVP,意大利.NET用户组负责人。现任Managed Designs公司首席软件架构师。...
    作者: Dino Esposito
    Dino Esposito是一位ASP.NET和AJAX方面的专家、受人欢迎的演讲者,并经常为MSDN Magazine撰写文章。他曾在Microsoft Press出版多本著作,包括《Programming Microsoft ASP.NET 3.5)和《Introducing Microsoft ASP.NET AJAX)等。
    同作者作品
    Microsoft.NET企业级应用架构设计
    ASP.NET 3.5核心编程
    .NET软件架构之美(英文影印版)(.NET软件架构设计圣经)
    作者: Andrea Saltarel1o
    Andrea Saltarel1o是一位解决方案架构师、咨询师和培训师,居住于意大利米兰。作为微软公司ASP.NET方面的MVP,他管理着意大利的微软.NET用户组,并经常在各种业界会议中演讲。
    同作者作品
    Microsoft.NET企业级应用架构设计
    .NET软件架构之美(英文影印版)(.NET软件架构设计圣经)
    7. Symbian OS架构手册:手机操作系统设计与演进
    原书名: The Symbian OS Architecture Sourcebook: Design and Evolution of a Mobile Phone OS
    作者: (英)Ben Morris
    译者: 陈广辉 谭利平 齐志峰 赵毅 许国平 罗常青 李伟
    丛书名: 移动终端软件开发系列丛书
    内容简介symbian os已经成为一种主流智能手机操作系统,并且正在从高端向中端市场普及,在手机的演进和发展中扮演着越来越重要的角色。本书包括18章和2个附录,首先追溯了symbian公司和symbian操作系统的产生和发展的背景,描述了symbian操作系统的架构,对symbian操作系统中面向对象的关键思想进行了分析,然后分层次地对symbian操作系统模型进行了完整的、高水平且结构化的描述,结合具体发展案例,对symbain操作系统的历史和演进的一些关键方面进行了深入研究。书中还通过与symbian操作系统开发的一些核心开发人员的回忆,努力探索symbian操作系统产生、演进的动力和核心要素。
    作译者介绍:BenMorris在1997年10月加入Psion软件公司,加入后在第一代C++产品和当时还是EPOC32操作系统的Java SDK的软件开发工具包团队中工作。他领导了一个为EPOC32系统ER5版本生产SDK的小团队,当Psion软件公司变为Symbian公司之后,他负责领导和扩展公司的系统文档团队。2002年,他加入了Symbian软件工程组织新成立的系统管理团队,该组织的主要目的就是“定义系统”。他设计发明了Symbian操作系统原始的系统模型,目前,他领导着负责维护和改进该模型的团队。
    8. 反模式:危机中软件、架构和项目的重构(软件工程圣经之一)
    原书名: AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis
    作者: (美)William J. Brown    Raphael C. Malveau    Hayds W.McCormick    Thomas J. Mowbray
    译者: 宋锐
    内容简介:模式是可以复用的优秀解决方案。本书从一个新的角度审视模式,提出了反模式的概念,介绍了在软件开发中常常出现的问题——将设计模式错误应用于不适当的上下文环境。首先,定义了软件开发参考模型和文档模板来说明这些反模式。然后,从开发人员角度、架构角度和管理角度三个方面对这些反模式逐一说明,并说明了与特定反模式相关的背景、原因、症状和后果,让读者可以迅速地检验身边的项目是否出现了这些状况,同时也针对每个反模式给出了相应的解决方案。
    作译者介绍William J.Brown曾任Saga软件公司研发总监和OMG金融业工作组主席。擅长金融行业大型软件系统的开发。
    9. 软件架构:组织原则与模式
    原书名: Software Architecture Organizational Principles and Patterns
    作者: (美)David M.Dikel 等   
    译者: 张恂 等
    内容简介:本书主要描述软件架构与软件组织之间的相互关系,依次介绍了作者根据多年管理经验和研究总结出的软件架构组织的vraps 5项原则——构想(vision)、节奏(rhythm)、预见(anticipation)、协作(partnering)和简化(simplification),并通过案例分析、模式和反模式展示了如何运用这一模型。

    展开全文
  • 软件架构设计书籍介绍

    千次阅读 2015-05-15 15:43:27
    1.软件架构设计  作者: 温昱  内容简介:本书紧紧围绕“软件架构设计”这一主题,立足实践解析了软件架构的概念、阐述了切实可行的软件架构设计方法、提供了可操作性极强的完整的架构设计过程。另外,本书...
    1.软件架构设计
      作者: 温昱
      内容简介:本书紧紧围绕“软件架构设计”这一主题,立足实践解析了软件架构的概念、阐述了切实可行的软件架构设计方法、提供了可操作性极强的完整的架构设计过程。另外,本书从思维方式的突破、面向对象设计、UML建模、过程与管理等关键过渡环节,为广大程序员的成长提供了切中肯綮的指导。本书可作为计算机软件专业本科生、研究生和软件工程硕士的软件架构设计教材,也可作为软件开发高级培训、软件开发管理培训的培训教材,更是第一线高级开发人员和开发管理人员的必备参考书。
      作译者介绍
      温昱,资深咨询顾问,CSAI特聘高级顾问,软件架构专家,软件架构思想的传播者和积极推动者。十年系统规划、架构设计和研发管理经验,在金融、航空、多媒体、网络管理、中间件平台等领域负责和参与多个大型系统的规划、设计、开发与管理。在《程序员》杂志、IBM DeveloperWorks等媒体发表了《图论思想与UML应用》、《敏捷设计从理论到实践》、《随需而变的RUP》等文章数十篇。译著有《应用框架的设计与实现——NET平台》等。
      作者: 温昱 
      温昱 资深咨询顾问,CSAI特聘高级顾问,软件架构专家。软件架构思想的传播者和积极推动者,中国软件技术大会杰出贡献专家。千年系统规划、架构设计和研发管理经验,在金融、航空、多媒体、电信、中间件平台等领域负责和参与多个大型系统的规划、设计、开发与管理。作为资深咨询顾问,已为众多知名企业提供了卓有成效的架构培训与咨询服务。 
      同作者作品
      软件架构设计(09年度畅销榜TOP50) 
      SQL语言艺术 (china-pub首发) (08年度畅销榜TOP50) 
      一线架构师实践指南(中大型系统架构设计指南) 
       2. 架构实战—软件架构设计的过程 
      原书名: The Process of Software Architecting 
      作者: (英)Peter EelesPeter Peter Cripps 
      译者: 蔡黄辉 马文涛 
      内容简介:本书从基本原理入手,介绍软件架构设计过程中涉及的一些概念、流程、方法、用到的工作产品及可重用的资源,从第6章开始,通过介绍一个具体的案例来阐述如何定义需求、创建逻辑架构、创建物理架构。在第10章“进阶”中,作者补充说明了架构师和软件开发项目其他方面的关系,后面又说明了各种软件开发项目可能存在的困难及相应的处理方法。
      本书理论结合实践,介绍了一些可以应用到整个或部分的架构设计流程中的最佳方法。不管你是一位资深的架构师还是一位有志于成为架构师的初级使用者,通过阅读本书都能从中获益。 
      作译者介绍
      Peter Eeles 是IBM的高级IT架构师,他就职于IBM的Rational品牌软件组。在这个职位上,他帮助组织提高软件开发能力,尤其关注和致力于改进架构流程。Peter从1985年开始从事软件行业,其主要工作是进行架构设计和实现大规模、分布式的系统。Peter是《Building J2EE Applications with the Rational Unified Process》(Addison?Wesley,2002)和《Building business Objects》(John Wiley & Sons,1998)的合著者。他还是英国计算机协会高级会员(FBCS)、工程技术协会(FIET)会员、IBM技术人员、Open Group 
       3. 面向模式的软件架构.第4卷,分布式计算的模式语言(经典POSA系列的第4卷) 
      原书名: Pattern-Oriented Software Architecture Volume 4: A Pattern Language for Distributed Computing 
      作者: (德)Frank Buschmann (英) Kevlin Henney (美)Douglas C. Schmidt 
      译者: 肖鹏 陈立 
      内容简介:本书关注分布式计算系统软件的设计和实现。书中首先介绍理解本书内容所需的核心的模式概念,分布式计算的好处和挑战;然后描述如何使用分布式计算模式语言,设计真实世界中仓库管理流程控制系统;最后重点讲述分布式计算模式语言,该语言陈述了创建分布式系统相关的技术主题。
      作译者介绍
      Fralk Buschmann是德国慕尼黑西门子技术公司的高级总工程师。他的研究领域包括对象技术、软件架构、产品线、模型驱动软件开发和模式。他在该领域著作甚多,其中最引人注目的便是POSA系列的前两卷[POSA1][POSA2]和最近的两卷:本书和[POSA5]。Frank在1992年至1996年曾是ANSIC++标准化委员会X3J16的成员,于1996年发起了首届EuroPLoP会议,与人合作汇编了数本模式方面的书籍[PLoPD3][SFHBS06],现任Wiley软件设计模式丛书的主编。
      译者: 肖鹏 
      肖鹏,ThoughtWorks高级咨询师,敏捷过程教练,面向对象分析和面向对象设计专家。拥有6年以上软件开发实践经验,多次担任国内大中型企业敏捷流程改进、面向对象分析和面向对象设计咨询和培训。他长期关注于设计模式、架构模式、敏捷软件开发等领域,并致力于软件开发最佳实践的推广和应用。
      同作者作品
      Visual Studio 2005技术大全(使.NET程序员事半功倍的利器) 
      Visual Studio 技术大全(微软技术大师力作) 
      面向模式的软件架构.第4卷,分布式计算的模式语言(经典POSA系列的第4卷) 
       4. 互联网时代的软件革命--SaaS架构设计
      作者: 叶伟 
      内容简介:本书是国内第一本完整介绍saas应用开发的书籍,聚集于架构设计。内容是互联网领域具有丰富实践经验的8位一线架构师,对于多年saas实践经验的总结。对于saas领域的业务、设计、开发人员,具有很高的指导价值。
      本书首先从saas的商业价值分析开始,讨论saas应用与其它应用最大的差异特征:多租户。saas应用架构是否成熟正是对多租户的三个重要特性的衡量:高性能、可配置性和伸缩性。本书将对saas应用成熟度的4个模型一一描述,并通过郭靖和杨康两个大学生的创业故事来描述saas应用逐步成熟到百万级以上租户时,应用软件的架构设计演变过程。
      同时,本书针对云计算、openapi、离线应用、安全以及开放平台等saas等相关的主题进行了深入的阐述。 
      作者: 叶伟 
      叶伟,阿里软件研发中心总监。曾先后就职于金仕达卫宁、IBM、金蝶,在HIS、ERP、SaaS领域领导开发了多个大型成功产品。复旦大学计算机科学学士、硕士,1993年获高级程序员,2000年被评为高级工程师。15年软件开发经验,专长面向对象分析&设计,以及SaaS应用架构设计。 
      同作者作品
      互联网时代的软件革命--SaaS架构设计(SD大会现场签售全国独家首发)(09年度畅销榜TOP50) 
      作者: 赵进 
      赵进,阿里软件首席架构师,在管理软件领域和SaaS领域都有多年的开发和架构设计经验。现负责阿里巴巴软件互联平台的技术规划和架构设计工作,对于云计算、PaaS、OpenAPI、MultiTenant架构、SOA、MDA等领域都具有浓厚的兴趣。
      作者: 叶军 
      叶军,计算机博士,阿里软件架构师。10年Web应用开发经验,对网站设计和互联网前沿技术有广泛的研究。现负责阿里软件互联平台的系统架构设计。 
      作者: 闻波 
      闻波,阿里软件桌面平台架构师。一直致力于Windows应用软件开发,对面向对象程序设计和Windows系统底层的研究有丰富的经验;对驱动程序开发、软件加密/解密等有较深入的研究。 
      黄晓龙,阿里软件高级架构师,先后在金蝶、腾讯等多家著名IT公司任职,在企业管理软件、架构设计、OOAD、敏捷开发、项目管理等方面积累了多年经验。
      龙良,阿里软件架构师,先后在金蝶、中兴等多家著名IT公司担任架构师。系统分析师(2005年),清华大学软件工程硕士。在Web架构设计和企业管理软件等方面积累了多年经验。 
      作者: 曾义 
      曾义,阿里软件Web平台技术经理,四川大学计算机科学硕士。专长于MDA、Web前端组件设计、SOA,目前领导SaaS应用开发平台XPlatform的研发 
      作者: 李战 
      李战,阿里软件架构师,从事SaaS研究多年。在SaaS数据库、Web架构、前端框架以及数据库全文检索方面都有丰富的经验。 
      作者: 莫建祥 
      莫建祥,阿里软件高级架构师。擅长大规模即时通信系统、分布式存储和数据库系统、分布式计算、高性能计算、网络通信的设计开发。现负责阿里旺旺(IM产品)的整体架构设计。 
       5. 企业应用架构模式(英文影印版)(企业应用开发圣经) 
      原书名: Patterns of Enterprise Application Architecture 
      作者: (美)Martin Fowler 
      内容简介:面向对象大师martin fowler及其专家级合作者将40多种常用解决方案转化成模式,为我们提供了这本能够应用于任何一种企业应用平台的、关于解决方案的参考书。本书叙述深入浅出,采用大量uml 图进一步阐明有关概念。前面介绍企业应用的背景知识,如分层架构、web表现、业务逻辑、数据库映射、并发、会话、分布策略等。在此基础上,随后的各章分别对与这些背景知识相关的设计模式进行了详细的介绍,并配以详细的java代码或c#代码示例。.
      本书适合设计和构建企业应用的软件架构师、设计人员和编程人员阅读,同时也可作为高等院校计算机专业及软件学院相关课程的参考教材。..
      随着信息技术的广泛应用,系统需要处理的数据量越来越大,企业级软件开发已经渐成主流,而开发人员面临的困难与挑战也是显而易见的。更糟糕的是,这一领域的资料一直非常缺乏。
      本书是软件开发大师martin fowler的代表作,采用模式的形式系统总结了业界多年积累的经验,被称为“企业级应用开发领域的圣经”,出版以来一直畅销不衰,至今仍然无可替代。作者在精彩地阐述了企业应用开发和设计中的核心原则基础上,详细、生动地讲述了51个模式并给出主流平台(java和.net)中的应用实例,更分析了许多相似模式之间的差异,提供了具体运用和选择这些模式的大量经验之谈,使你不仅知其然,更知其所以然。
      这是一部软件开发领域不朽的经典,任何一位真正的软件开发人员都不可错过。... 
      作译者介绍
      Martin Fowler 享誉世界的软件开发大师,现为著名软件开发咨询公司ThoughtWorks的首席科学家。他在面向对象分析与设计、UML、设计模式、软件开发方法学、 XP、重构等方面都有重要贡献。他更是全球最具影响力的技术作家之一,除本书外,他的《分析模式》、《UML精粹》、《重构》等著作都已经成为经典。
      作者: Martin Fowler 
      Martin Fowler是一位独立咨询顾问,他运用对象技术解决企业问题已经超过十年。他的顾问领域包括健康管理、金融贸易,以及法人财务。他的客户包括Chrysler,Citibank,UK National Health Service,AndersenConsulting,NetscapeCommunications。此外Fowler也是objects、UML、patterns技术的一位合格讲师,他是《AnalysisPatterns》和《UML Distilled》的作者。 
      同作者作品
      企业应用架构模式
      UML精粹:标准对象语言简明指南(第3版) 
      UML精粹:标准对象建模语言简明指南(第3版)(英文影印版) 
       6. .NET软件架构之美(英文影印版)(.NET软件架构设计圣经)
      原书名: Microsoft .NET: Architecting Applications for the Enterprise 
      作者: (意)Dino Esposito Andrea Saltarello 
      内容简介:软件架构设计是现代软件开发的核心,它不仅是一门技术,更是一门艺术。然而,长期以来,一直没有一本讲述.net架构设计的书。.
      本书填补了这一缺憾。两位作者人选可谓众望所归,他们将gof设计模式、martin fowler企业架构模式、eric evans领域驱动设计等业界精华与自己多年软件开发实战经验结合起来,深刻阐述了软件架构设计思想精髓。作者还从技术架构角度逐章讲述了业务层、服务层、数据访问层和表现层的分层设计,同时介绍了各种软件架构设计方案的优与劣,如何在各种方案中做出抉择,以及如何将这些设计原则更具体地应用到应用程序中。..
      本书出自两位具有多年软件开发经验的 asp .net专家、作者和培训师之手,内容涉及多层架构、设计模式以及设计原则。第一部分简要介绍 uml、设计原则及模式;第二部分从技术架构角度讨论分层设计。本书行文流畅,语言通俗易懂,阐述了各种架构设计技术方案的优与劣,并讲述了如何在优与劣中做出权衡。中设计了真实的场景,展示了如何将这些设计原则更加具体地应用到 .net应用程序中。
      本书适合各层次 .net开发人员阅读。... 
      作译者介绍
      Dino Esposito .NET和软件架构技术方面的世界权威,微软ASP.NET MVP。目前就职于著名的.NET技术咨询公司IDesign。他是广受欢迎的技术作家,担任MSDN Magazine特邀专栏作家多年,并撰有Programming ASP.NET 3.5 Core References等名著。.
      Andrea Saltarello 微软ASP.NET MVP,意大利.NET用户组负责人。现任Managed Designs公司首席软件架构师。...
      作者: Dino Esposito 
      Dino Esposito是一位ASP.NET和AJAX方面的专家、受人欢迎的演讲者,并经常为MSDN Magazine撰写文章。他曾在Microsoft Press出版多本著作,包括《Programming Microsoft ASP.NET 3.5)和《Introducing Microsoft ASP.NET AJAX)等。 
      同作者作品
      Microsoft.NET企业级应用架构设计 
      ASP.NET 3.5核心编程 
      .NET软件架构之美(英文影印版)(.NET软件架构设计圣经) 
      作者: Andrea Saltarel1o 
      Andrea Saltarel1o是一位解决方案架构师、咨询师和培训师,居住于意大利米兰。作为微软公司ASP.NET方面的MVP,他管理着意大利的微软.NET用户组,并经常在各种业界会议中演讲。
      同作者作品
      Microsoft.NET企业级应用架构设计 
      .NET软件架构之美(英文影印版)(.NET软件架构设计圣经) 
       7. Symbian OS架构手册:手机操作系统设计与演进 
      原书名: The Symbian OS Architecture Sourcebook: Design and Evolution of a Mobile Phone OS 
      作者: (英)Ben Morris 
      译者: 陈广辉 谭利平 齐志峰 赵毅 许国平 罗常青 李伟 
      丛书名: 移动终端软件开发系列丛书 
      内容简介symbian os已经成为一种主流智能手机操作系统,并且正在从高端向中端市场普及,在手机的演进和发展中扮演着越来越重要的角色。本书包括18章和2个附录,首先追溯了symbian公司和symbian操作系统的产生和发展的背景,描述了symbian操作系统的架构,对symbian操作系统中面向对象的关键思想进行了分析,然后分层次地对symbian操作系统模型进行了完整的、高水平且结构化的描述,结合具体发展案例,对symbain操作系统的历史和演进的一些关键方面进行了深入研究。书中还通过与symbian操作系统开发的一些核心开发人员的回忆,努力探索symbian操作系统产生、演进的动力和核心要素。
      作译者介绍:BenMorris在1997年10月加入Psion软件公司,加入后在第一代C++产品和当时还是EPOC32操作系统的Java SDK的软件开发工具包团队中工作。他领导了一个为EPOC32系统ER5版本生产SDK的小团队,当Psion软件公司变为Symbian公司之后,他负责领导和扩展公司的系统文档团队。2002年,他加入了Symbian软件工程组织新成立的系统管理团队,该组织的主要目的就是“定义系统”。他设计发明了Symbian操作系统原始的系统模型,目前,他领导着负责维护和改进该模型的团队。
       8. 反模式:危机中软件、架构和项目的重构(软件工程圣经之一) 
      原书名: AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis 
      作者: (美)William J. Brown Raphael C. Malveau Hayds W.McCormick Thomas J. Mowbray 
      译者: 宋锐 
      内容简介:模式是可以复用的优秀解决方案。本书从一个新的角度审视模式,提出了反模式的概念,介绍了在软件开发中常常出现的问题——将设计模式错误应用于不适当的上下文环境。首先,定义了软件开发参考模型和文档模板来说明这些反模式。然后,从开发人员角度、架构角度和管理角度三个方面对这些反模式逐一说明,并说明了与特定反模式相关的背景、原因、症状和后果,让读者可以迅速地检验身边的项目是否出现了这些状况,同时也针对每个反模式给出了相应的解决方案。 
      作译者介绍William J.Brown曾任Saga软件公司研发总监和OMG金融业工作组主席。擅长金融行业大型软件系统的开发。
       9. 软件架构:组织原则与模式
      原书名: Software Architecture Organizational Principles and Patterns 
      作者: (美)David M.Dikel 等 
      译者: 张恂 等 

      内容简介:本书主要描述软件架构与软件组织之间的相互关系,依次介绍了作者根据多年管理经验和研究总结出的软件架构组织的vraps 5项原则——构想(vision)、节奏(rhythm)、预见(anticipation)、协作(partnering)和简化(simplification),并通过案例分析、模式和反模式展示了如何运用这一模型

    转自:http://blog.sina.com.cn/s/blog_6364150101015lyl.html

    展开全文
  • 作者:人月神话,新浪博客同名简介:多年SOA规划建设,私有云PaaS平台架构设计经验,长期从事一线项目实践今天准备再详细讲解下业务系统软件架构设计方面的内容,我在前面的文章专门写过一篇软件架构师应该走出技术...
    5e2fb3726fb4e52918aedd1fb1b2f611.png

    作者:人月神话,新浪博客同名

    简介:多年SOA规划建设,私有云PaaS平台架构设计经验,长期从事一线项目实践

    今天准备再详细讲解下业务系统软件架构设计方面的内容,我在前面的文章专门写过一篇软件架构师应该走出技术狂热误区,锻炼核心架构思维能力的文章。

    在这篇文章里面我对架构思维做了一个简单总结。

    94d6f7155735af7e0bcee8c2cdf11d18.png

    其核心仍然是我们常说的分解,集成,抽象,复用,分层等思维模型。感兴趣的可以先阅读这篇文章的一些内容。软件架构师应走出技术狂热误区,锻炼核心全局思维能力

    在这篇文章里面更多的是篇架构思维和企业架构方面的内容,因此今天这篇准备从单个业务系统的架构设计来谈下软件架构设计的核心逻辑和内容。

    对于软件架构设计,相信很多人都看过温昱写的一本《软件架构设计》书籍,而对于我这篇文章重点会参考企业架构,RUP架构设计和这本书的一些思想做一些展开。

    软件架构设计概述

    2c7c8371f499f61ef6d60eb4066b2149.png

    架构设计包括了功能性架构和技术架构设计两个部分的内容,功能性架构解决业务流程和功能问题,而技术架构解决非功能性需求等问题。两种架构都包括了动态和静态两个方面的内容,对于功能性架构中动态部分为业务流程驱动全局用例,用例驱动的用例实现等;对于技术架构中动态部分为架构运行机制,而静态部分为框架,分层等方面的内容。

    功能性架构包括了全局用例设计,这个本身是用例分析和设计的一个延续,而全局用例分析建议的思路仍然是业务流程,业务用例建模到系统用例建模的过程。

    全局用例分析清楚后可以开始考虑子系统和模块的划分,形成系统的功能架构图,当然在划分过程中一定要考虑到通过CRUD矩阵等分析方法来分析模块如何划分合理,如何保证模块本身高内聚和松耦合。

    即我们说的从00-用例视图如何过渡到01逻辑视图架构。

    在全局用例分析完成后涉及到数据模型的设计,数据建模仍然从业务驱动,从最初的业务对象和单据入手,到最终的数据概念模型和逻辑模型等。

    架构设计中全局数据模型不一定覆盖所有的数据对象和数据表;但是核心的主数据,核心业务单据数据一定要覆盖到,模型到的层次到逻辑模型即可。如果用面向对象的分析方法,这里需要出的是UML建模中的概念模型和逻辑模型,体现核心对象和类,核心对象和类之间的关系

    36c692f1b2f41962a65bf6c321128554.png

    将全局用例分析和数据模型建立融合在一起,可以看到这两者结合起来会形成一个系统完成的领域模型层。一直认为领域模型思路应该引入架构设计,只有领域模型才是真正关注功能性架构,而不用马上关注到具体的技术分层和技术实现。

    前面两者做完后可以看到一个大系统被分解为了多个子系统或模块,那么接着要考虑的就是模块间的集成架构,分析完集成架构模块间的接口基本就出来了。接口设计应该是架构设计的另外一个核心内容。要明白架构设计一个重要作用就是架构设计完成后各个模块可以并行开始概要设计,详细设计和开发工作。只要大家都遵循架构设计约定的接口规则即可以了。

    以上正好是架构视图中的01逻辑视图的关键内容。

    集成架构考虑完另外一个核心内容就是公共可复用组件的抽取和识别,包括了功能组件和技术组件,需要识别出来哪些是可复用的,如何进行复用。对于复用层次本身又包括了数据层复用,逻辑层组件复用,界面层UI组件的复用等。复用是架构价值体现的的另外一个关键点。

    这些都做完后,接着一个步骤应该在架构设计阶段做的就是对架构输出成功进行模拟验证,前面完成了分解动作,必须通过模拟验证来看看后续分解内容能否很好的集成和组装。很多时候我们做架构设计的时候往往不做这块内容,导致架构设计一些内容变成空中楼阁,无法落地。

    63b389c1305affe43b07db17335ef86b.png

    再回来看技术架构设计,首先谈下静态部分的内容。这里面就包括了软件开发的分层架构,开发框架等内容,包括开发规范约定,技术平台和语言的选择,使用的规约等都需要考虑。这些可以看到刚好是4+1架构视图里面的02开发视图的内容。很多时候我们看到谈架构的时候说到的三层或多层架构,仅仅是完整架构设计里面很小的一部分内容。

    除了分层架构外,接着考虑的就是各种非功能性需要,我们在架构上需要如何设计。

    这里面包括了事务,缓存,异常,日志,安全,性能,可用性,容错能力等。这些逐个点都要在架构设计中说清楚如何考虑,由于这些本身就属于一个应用系统中技术平台要考虑的内容,因此应该设计为较为公用的技术组件供上层的业务组件使用。要明白很多时候为何谈到AOP或可插拔架构,只有这样去考虑问题,才会考虑真正的功能性架构设计和功能实现和非功能性技术架构这块充分解耦,实现进一步的灵活装配。而这个对应架构视图里面的03进程视图

    再回到架构设计视图层面,还需要考虑的就是整个应用系统的部署架构,部署架构本身也包括了逻辑视图和物理视图,应用最终开发出来了如何进行部署,这涉及到了IT基础架构方面的细化,也需要考虑清楚。即架构视图里面的04部署视图

    软件架构设计的内容

    一说到软件架构设计包括的内容,我们比较容易想到的就是传统RUP和面向对象分析和设计里面经常谈到的4+1架构视图,如下:

    94bdc39bf863b3ecd7777486f87b14d9.png

    从这个图也更好的解释了软件架构应该包括功能性架构和非功能性架构两方面内容。

    逻辑视图即是从功能需求视角,逻辑视图更多的就是组件划分,组件间的依赖关系,当然你可以进一步细化到核心的类和类关系图。但是一般来讲搞清组件和组件间关系最重要。

    对于非功能性需求实际有两个方面的考虑。

    • 开发态:即技术和开发框架选择,开发分层模型
    • 运行态:系统集成视角,进程视图,对于性能和可扩展性的考虑

    当然RUP更加强调的是用例驱动,即最中心的是用例视图,用例视图是展开后续架构分析设计的基础。如果熟悉RUP方法论也可以看到,对于用例实现的分析才能够识别出关键的实体类,控制类和边界类,在类识别出来后才能够进行后续的组件划分和接口集成分析等。

    在我写这篇文章的时候,到网上搜索关于RUP架构设计的资料,发现最近几年基本没有更新的技术资料,难道是当前敏捷开发和微服务不需要完整的架构设计了?实际上我们看到当前很多微服务项目建设后续出现大量紧耦合,低性能等问题,完全是由于前期架构设计不充分导致。错误的将采用类似SpringCLoud框架作为我们完成架构设计是当前最大的问题点。

    当我重新翻阅了下多年前写过的软件架构设计文档,基本即是参考RUP架构设计展开。

    5070c0d20c2da4a711efdd7c67c694e2.png

    但是在进行架构设计的时候,实际我们已经有一些重要的输入,一个是来自于业务系统本身,一个是来源于组织级技术资产积累。

    • 业务系统:核心是产品需求和软件需求,已经进行业务建模和业务组件划分
    • 组织资产:包括技术平台,技术组件,技术框架标准,可复用技术清单等

    这些一方面是业务系统进行架构设计的输入,同时也是架构设计的关于约束。架构设计一方面是要实现业务目标和需求,一方面又必须满足关键约束。这些约束可以技术框架要求,开发语言和数据库要求,多中心化的要求等等,这些在架构设计的时候都必须考虑到。

    基于以上思考和近期的项目实践,对于软件架构设计文档我们给出一个新的参考,但是其核心仍然是围绕业务,数据,应用,技术几个维度展开。

    即一个完整的软件架构设计应该包括如下内容:

    d5f290f6793059ea0b7f7e717d046aa1.png

    基于该图,有几个关键说明如下:

    对于架构设计文档可以拆分为软件架构设计,数据库设计,部署架构设计三个独立文档。而实际我们项目建设和实践三个文档基本也进行拆分。

    其次对于软件架构设计文档应该从架构目标约束出发,基于业务需求和用例输入,进行功能性架构设计和非功能性架构设计,同时在这里将技术开发框架和分层架构设计单独出独立章节,即不管是MVC还是SSH,都是标准分层框架模型,你只需要讲清楚架构运行机制即可,不需要和实际业务功能相关。

    在关键架构设计内容梳理清楚后,我们再讲解下架构设计文档的核心内容逻辑。

    从用例视图到逻辑视图

    61937ef579c796ca5244dd1b9fe26fc1.png

    如果熟悉RUP方法论的可能都清楚,在RUP统一过程方法论里面有三个核心。其一是用例驱动,其二是架构为核心,其三是增量迭代方法论。

    在用例分析和设计中,基本梳理清楚了核心的业务功能点,核心的业务对象,同时在详细的用例需求文档里面还有详细的业务基本流,扩展流和业务规则描述。

    在传统的用例分析里面我们没有太去强调业务域的划分和业务架构概念,但是这个实际仍然是需求阶段一个重要的内容。即通过用例分析后我们需要对用例点进行聚合,形成一个业务架构模型图

    这个业务架构图形成了基本的业务模块或业务组件,如下:

    6d72422bd5adb5f1f1a2e0028e72257f.png

    在我们原来的整个软件生命周期管理里面,除了软件需求外,还会有一个独立的产品需求文档,即在产品需求文档里面会进行产品业务模块-》业务单元-》业务功能的分层定义。

    也就是说在需求阶段完成了业务建模,并完成了业务组件划分。

    7c8f2da55e6b437527f8bad1f694e089.png

    有了产品需求和业务架构,那么架构设计阶段就有了重要的参考。但是如果你没有完整的业务建模,那么在架构设计阶段,需要首先做的就是业务组件划分。

    对于组件的划分,我在前面一篇文章中给出了一些指导原则可参考:

    中台规划中微服务粒度究竟应该如何划分?你可以从以下几点考虑

    8b2ac4795f94fa54d0ac85db31320c50.png

    那么划分的核心点究竟在哪里?

    我们通过组件划分要达到高内聚和松耦合,但是这个是划分后的目标而不是方法。真正划分的方法仍然是围绕业务功能,业务数据,业务流程三者之间的各种CRUD功能和数据交互分析

    通过交互分析你才能够发现真正的哪些业务功能或业务数据应该聚合在一起。

    逻辑视图首先要解决组件划分

    对于逻辑视图,对原来的方法做一定的修正。

    即传统架构视图里面的逻辑视图更多的是核心类和类关系视图,而个人理解在架构设计阶段并不一定要细化到这个层次,更加重要的是组件划分和组件关系集成视图。

    即在逻辑视图设计的时候,需要首先进行组件划分,组件划分的方法可以参考业务建模,如果没有业务建模可参考那么就需要重新进行业务,数据,流程的CRUD分析来划分组件单元。

    而对于组件划分的方法,我们可以理解为最传统的纵向划分思路和当前结合了领域建模和SOA分层架构思想的分层组件划分思路。

    我们先看一个传统的组件划分的例子,如下:

    7b36951ce7bead67f531dc5f247c2d5d.png

    上图就是一种典型的纵向划分思路,即业务组件+开发分层模型形成组件划分和组件架构图。而这种组件划分和设计思路,是很难真正体现我们常说的领域模型设计逻辑的。

    基于SOA和领域模型设计的思路,更多的我们应该是首先找到共性的领域层服务能力,然后再基于领域模型能力来构建上层的业务功能和流程功能。

    即从纵向组件划分思路=>SOA和领域分层模型构建思路。

    横向分层有点类似你首先去考虑构建领域模型,再来考虑上层业务功能,上层的业务功能模块和领域模型层的组件不再是简单的纵向1对1关系。这个和当前我们做中台架构规划设计很类似,即先考虑如何构建中台共性业务能力,再来考虑前台业务功能如何划分组件。

    我基于PLM系统常见的文档管理,ITEM管理,产品结构和变更管理等业务功能组件模块,基于分层构建的思路重新对组件划分和组件模型进行重构,参考如下:

    cced952b34a5e0ad59563b02d86577ad.png

    在这里基于个人理解再强调一点,在我们进行架构设计中的逻辑视图设计的时候,一开始务必不要陷入到技术开发框架的分层模型中去。而是应该找寻最核心的领域模型。

    为什么这样讲?

    领域模型更多的体现了核心的领域实现逻辑,这个领域模型本身是和你采用的技术开发框架无关的,你可能是三层MVC框架,也可能是其它的前后端四层框架等等,但是这些本质上都不影响到你领域模型的设计。这是领域模型的技术无关性。

    也就是在RUP的逻辑视图不应该过早陷入到架构分层模型中。

    对于技术框架和架构分层,本身是一个完全技术概念,和逻辑模型相反的地方是其本身和业务无关,但是任何的业务功能具体实现,都必须遵循分层架构和层级业务和数据调用流转机制。

    当我们理解到这点后,就更加容易理解逻辑视图和开发视图的关系,即如下:

    1b8c7a5ade6c99b18fdf55e72b8db9d8.png

    从组件划分到用例实现分析

    注意组件划分不是一成不变,你开始的组件划分可能并不合理,这个可以在后续用例实现的过程分析中对个别功能点的归属进行调整。

    这也是我们说的架构分析设计过程也是一个不断迭代和求精的过程。

    当然在需求阶段,我们就应该形成一个全局用例分析图。

    48567fb4a8d204ea68088fcc1397efc7.png

    在这里我们做两个关键说明,即如下

    • 不是对所有用例进行实现分析,只对关键用例进行
    • 用例实现分析只到组件,而不是到具体的类

    对于第一点大家容易理解,一个架构设计不可能对所有的用例进行分析。那么什么是关键用例?比如你当前有一个文档管理模块,那么对于文档的增删改查功能实现是否是关键用例?

    那么我的答案是这种不是关键用例,我们对关键用例给出一个新的定义,即关键用例往往是跨了多个组件协同才能够完成的用例。如果一个用例实现在一个组件内部就能够搞定,那么我们可以把这部分工作放到概要设计或详细设计去做,而不是在架构设计阶段完成。

    d9da4335b697838c33960b25a3ce6411.png

    当我们对关键用例完成分析后,你会发现组件之间的集成和协同关系也就出来了。而且这个时候你很清楚为何组件之间存在这么一个集成点。

    将所有的集成点都找到后,组件间的集成关系图也就基本清楚了。

    b128687ccdbfc12e587253eab0715fba.png

    那么再下一步就是基于集成点梳理接口清单。

    对识别出来的接口进行分析,看哪些接口需要拆分,哪些接口需要合并,接口服务如何保证我们常说的粗粒度特性。在这个步骤完成后才能够形成完整的接口清单。

    bdc95be768e203561c386555212c52c6.png

    到了这里我们基本完成了逻辑视图最核心的内容,即具体应该分为哪些组件,这些组件如何协同来完成关键用例实现。组件之间的接口集成关系是如何的,接口如何抽象和复用。

    59110f10120a20908c3bd5b665abcbe7.png

    当然你可以看到逻辑视图可以再进一步细化,比如对于组件关系图你可以进一步细化到类关系图,对于关键用例实现可以细化到类之间的详细方法定义和交互。即逻辑架构设计再朝下面细化了一步,但是整体细化仍然和我们前面谈到的逻辑架构分析设计思路一致。

    从架构分层到开发视图

    开发架构关注软件开发环境下实际模块的组织。软件打包成小的程序块(程序库或子系统),它们可以由一位或几位开发人员来开发。子系统可以组织成分层结构,每个层为上一层提供良好定义的接口。系统的开发架构用模块和子系统图来表达,显示了"输出"和"输入"关系。完整的开发架构只有当所有软件元素被识别后才能加以描述。但是,可以列出控制开发架构的规则:分块、分组和可见性。

    7a54bd6f96fc0830e8ae01219ec3f368.png

    再次强调下如果你自己没有完成过一个全新系统的架构设计,那么你很难真正了解到架构设计的完整内容。作为一个架构师必须既了解业务,又了解技术,同时做好业务到技术的抽象转换,做好业务和技术之间的桥梁和承接。

    你掌握SSH三层框架,或者说你使用SpringCloud微服务框架,完成框架搭建,搞清楚里面的每一个技术组件的作用可能一周时间足够。或者类似你基于Hadoop整个技术体系搭建一个完整的大数据平台,了解数据存储,处理,分析等关键技术组件估计1到2个月也足够。但是你学会后不能叫架构师,核心原因还是架构不能脱离业务,架构是需要业务驱动去解决业务场景和问题的。

    脱离业务实际上就没有架构设计,最多只能够算的上架构设计中的技术框架选型。但是我们看到,如果你不清楚具体的业务需求和目标,你连究竟技术框架如何选型也不清楚。

    一个好的架构一定不是用最先进的技术,而是用最适用的技术,是真正的业务目标驱动你要用哪些技术,而不是当前流行什么我必须采用什么技术。

    在前面有篇文章里面我就谈到过,当前有些技术人员一味的使用新技术,新框架来搭建企业技术平台和开发框架,而不是从企业实际业务需求和架构约束出发。在这个过程中自己能力提升了,技术框架不适用自己可以一走了事,但是企业却很受伤。这不再是简单的技术人员技术狂热问题,而已经是一种个人自私自利行为表现。

    那么对于一个开发视图究竟应该包含哪些内容,我们参考网上的一个说法:

    9a4f9a64b05e7b7709eed1f2a44bfe38.png

    简单来说开发架构就是需要技术框架选型,开发的分层架构,开发标准规范体系,开发技术选型,这些属于标准的和业务功能模块无关的内容。

    其次就是我们说的基于已有的逻辑视图和功能,你在开发的时候应该如何划分项目,如何分包,整个项目源代码的结构是如何的,各层和各层之间的关系是如何的。

    也就是我前面谈到的逻辑视图+技术框架分层=完整的开发视图

    1b8c7a5ade6c99b18fdf55e72b8db9d8.png

    在逻辑视图中的要给组件实现,如果在开发视图中往往可能会体现到多个分层的Package包,比如我们常说的数据层,逻辑层,展现层等。

    同时我们考虑到开发的需要,一个大的业务系统我们可能一开发就拆分多个独立的开发项目进行管理,每个项目都可以进行独立的构建和编译。那么整体的开发视图分层应该为:

    开发项目(子系统)=》开发包(分层)=》开发功能(具体类文件)

    一个完整的开发架构除了选择一种标准的技术开发框架外,更加重要的就是你需要定义清楚具体的开发项目划分,项目里面的目录和分层结构,类文件的命名规范,接口的定义和调用规范等。

    这些规范和开发要求将指导我们进行每一个业务功能点的开发。即使最简单的一个业务功能你也可以看到需要具体在每层写哪些类文件,哪些接口和接口实现文件,哪些配置文件等。

    在开发架构下,对于逻辑架构里面的组件架构图会得到进一步的细化。

    即原来的组件粒度-》变化为分层构件粒度

    其次,在开发架构中,我们还需要考虑会引用哪些外包的开源组件,第三方的SDK包等。这些内容属于通用技术框架内容,在逻辑架构设计阶段我们一般不会关心。

    我们还是用前面的例子进一步说,一个PLM系统包括文档,产品,变更三个大模块。如果整体我们就一个开发项目,在开发项目内部进行分包,我们开发架构类似如下:

    d932b13a00f36ea4ec15d8597c61288c.png

    在开发架构构建过程中,我们将文档管理,产品管理和变更管理三个模块建立三个独立的项目,同时当变化为三个独立项目后,我们要求原来包内组件间的依赖,只能够存在业务逻辑层相互依赖和调用,不能再出现跨模块和跨层的依赖调用以减少拆包后的耦合关系。

    基于以上场景,我们整个开发架构变化为:

    60feeb6075ddec9375b077c2be8bcf62.png

    再次,当我们进一步进行前后端分层,同时将数据库访问层进行统一,即数据访问层建立一个统一的开发项目提供对外的数据访问接口。而对于前端开发合并为一个项目进行。而在领域服务层,我们进一步将原来领域逻辑归类到文档服务和产品服务两大领域服务,不再有具体的变更领域服务的概念。

    对于文档和产品两大领域服务可以看做是中台的两个大微服务模块,也采用分项目独立开发构建的模式进行。那么在这种变化下,我们的开发架构视图如下:

    339d732301e148960c40950827f26a9e.png

    通过前面几种场景的比较,主要是想说明开发架构更多的是要说明我们的组件如何分包和分层,组件的开发如何与我们当前的技术框架选型,我们的开发模式相互结合。

    而这些属于开发态的内容,需要在开发态才能够看得更加清楚。

    那么开发视图和运行视图之间的差别又在哪里呢?

    到了进程或部署视图,我们就只能够看到具体的独立部署单位,比如上图,只能够看到数据层一个独立的JAR包,逻辑层两个独立的JAR包文件,前端一个独立的JAR包文件。但是对于JAR包文件里面具体的包划分,分层划分在运行态或运行视图我们是看不到的。

    从进程视图到非功能性架构设计

    1bfb35a0f5a0fd15f8279dc1e7f4d1f0.png

    我们先摘录一段网上关于进程视图的描述,如下:

    进程架构考虑一些非功能性的需求,如性能和可用性。它解决并发性、分布性、系统完整性、容错性的问题,以及逻辑视图的主要抽象如何与进程结构相配合在一起-即在哪个控制线程上,对象的操作被实际执行。

    进程架构可以在几种层次的抽象上进行描述,每个层次针对不同的问题。在最高的层次上,进程架构可以视为一组独立执行的通信程序(叫作"processes")的逻辑网络,它们分布在整个一组硬件资源上,这些资源通过 LAN 或者 WAN 连接起来。多个逻辑网络可能同时并存,共享相同的物理资源。

    进程是构成可执行单元任务的分组。进程代表了可以进行策略控制过程架构的层次(即:开始、恢复、重新配置及关闭)。另外,进程可以就处理负载的分布式增强或可用性的提高而不断地被重复。软件被划分为一系列单独的任务。任务是独立的控制线程,可以在处理节点上单独地被调度。

    大家看了上面的进程视图描述啥感觉?

    实际上我们看到在业务系统的架构设计里面往往并不涉及到这么复杂的进程和任务处理逻辑。如果你是设计一个微服务底层架构或消息中间件,我们感觉会出现类似上面的进程视图描述。

    比如我们看Dubbo的技术实现框架,就类似于一种进程视图的表现方式。

    03e7a58ea0b508793a98451e235064c5.png

    但是对于大部分业务系统来说,往往并没有复杂的进程视图需要描述。

    5b1d8027f72739138320725ee4a022a1.png

    但是进程视图更多的是运行架构和运行态的软件质量属性总结。

    即我们常说的运行态的安全,性能,扩展性,可靠性,吞吐量等都需要在运行视图和运行架构中进行描述。而这些恰好是我们前面提到的非功能性架构设计的基础。

    b3ceac4598dceca1367a8c02984df25f.png

    当然对于非功能性架构设计,运行视图是主要内容,而对于开发架构,部署架构仍然需要提供对非功能性架构能力的支撑。比如我们常说的高并发和性能问题,那么你在开发框架和技术选择上就需要考虑,其次在部署架构本身的扩展性上也需要考虑。

    对于高可用,高性能和高扩展的非功能性架构设计,我准备单独再写一篇文章来说明,不在这篇文章进行展开。


    欢迎关注@人月聊IT 分享SOA,微服务,DevOps平台规划和建设。

    展开全文
  • 软件架构综述

    2020-09-29 10:50:14
    软件架构概述软件架构产生的背景软件架构的主要思想和特征主要思想软件架构的特征软件架构的发展阶段软件架构研究和应用现状软件架构理论和方法研究软件架构的应用研究参考书籍备注 软件架构产生的背景   软件架构...
  • 软件架构模式笔记

    千次阅读 2016-09-01 09:33:35
    本文内容整理自Mark Richards所著书籍软件架构模式》(Software Architecture Patterns)。分层架构 模式特点 模式分析 事件驱动架构 中介Mediator拓扑结构 代理Broker拓扑结构 模式分析 补充 微内核架构 模式分析 ...
  • 软件架构设计经典书籍有哪些

    千次阅读 2015-12-03 14:10:44
    内容简介:本书紧紧围绕“软件架构设计”这一主题,立足实践解析了软件架构的概念、阐述了切实可行的软件架构设计方法、提供了可操作性极强的完整的架构设计过程。另外,本书从思维方式的突破、面向对象设计、UML...
  • 本套“架构之美”系列丛书,以期从业务梳理、流程建模、软件架构、设计模式等方面进行系统、全面地介绍。强调理论与实践相结合,国外发展趋势与国内本地应用相结合,打造华人精品书籍,给国内读者提供真正有指导意义...
  • 软件架构设计经典书籍有哪些?

    万次阅读 2011-12-03 11:51:51
    1.软件架构设计 作者: 温昱 内容简介:本书紧紧围绕“软件架构设计”这一主题,立足实践解析了软件架构的概念、阐述了切实可行的软件架构设计方法、提供了可操作性极强的完整的架构设计过程。另外,本书从思维...
  • 本套“架构之美”系列丛书,以期从业务梳理、流程建模、软件架构、设计模式等方面进行系统、全面地介绍。强调理论与实践相结合,国外发展趋势与国内本地应用相结合,打造华人精品书籍,给国内读者提供真正有指导意义...
  • 软件架构学习1

    2020-02-16 15:09:53
    这段时间,因为业务要求,开始学习一些架构设计方面的东西,以前写代码,都按业务需求,进行开发,会有涉及设计,但不规范,很多东西没有系统学习,总有些不足的地方,因此,买了本架构相关的书学习,在此,写下我...
  • 软件架构概念

    2009-11-23 08:42:00
    前几天,有几个以前的同事到我家来玩,席间大家讨论到目前流行的软件架构。这些同事大部分目前转向从事软件架构工程师工作,有的想成长为软件架构工程师。大家共同的感受是抛开具体项目谈论软件架构都觉得很简单,不...
  • 本文档用来确定Nios的软件架构,以便帮助软件工程师更好的完成中控机的业务逻辑功能。 1.1.2 使用范围 本文档适用于飞利信的流媒体总线有线数字会议系统,中控机和终端开发工程师,以及相关产品经理和项目经理。   ...
  • 软件架构漫谈

    千次阅读 2016-06-05 15:15:12
    那么什么是软件架构呢?按照惯例,我们来看看是什么问题,是谁的问题。  要解决谁的问题?  如前所述,软件实际上就是把现实生活模拟到计算机中,并且软件是需要在计算机的硬件中运行起来的。要做到这一点需要...
  • 嵌入式软件架构的设计

    千次阅读 多人点赞 2019-02-18 22:00:35
    嵌入式软件架构的设计 大多数嵌入式程序员学习编程,都是从开发板的附带例程开始。之后工作也会继续参考那些例程,很多编程习惯、方式也会受之影响。 其实开发板式的编程方式与工作中实际需求的并不完全一致。 ...
  • 接触业务架构工作之后,除了单位提供的方法论外,为了做好这项工作,认真学习了软件过程、系统分析与设计、架构设计、设计模式、Java 语言等内容,并研读了敏捷开发、领域驱动设计、工作流分析等方面的书籍,为了...
  • 软件架构模式概述

    千次阅读 2016-09-17 12:15:20
    软件架构模式概述
  • 软件架构

    千次阅读 2007-09-04 09:48:00
     软件架构的重要性是不然而喻的,但是当所有人都意识到他的重要性的时候,却很少有人能够清晰的描述出如何能够提高软件质量  软件质量况架的目的就在于提出一个评价的原型,帮助我们分析一种方法和技术是否能够...
  • 学习软件架构设计

    2015-06-08 11:53:41
    为了帮助网友解决“想学软件架构设计,有什么好书推荐吗?”相关的问题,中国学网通过互联网对“想学软件架构设计,有什么好书推荐吗?”相关的解决方案进行了整理,用户详细问题包括:最近负责新项目的架构设计,发现...
  • 在软件开发设计中我们经常会面对业务分析,提取领域问题,从而实现软件架构设计。关于 软件架构设计Martin Fowler在2004出版的《企业应用架构模式》中 概括了四种方式的架构模式。它们分别为事务性脚本,表驱动模式...
  • 1.什么是软件架构?人人都在说软件架构,但人们并不能给出一个准确的定义,就像MartinFolwer在《Making Architecture Matter》上分享说的,Archite...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 30,254
精华内容 12,101
关键字:

业务软件架构书籍