

网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!
三层C/S架构
结构:将应用功能分成表示层、功能层和数据层三个部分
- 表示层:是应用的用户接口部分,它负担着用户与应用间的对话功能。它用于检查用户 从键盘等输入的数据,并显示应用输出的数据。在变更用户接口时,只需修改显示控制和数据检查程序,而不影响其他两层。检查的内容也只限于数据的形式和取值的范围,不包括有关业务本身的处理逻辑。
- 功能层:相当于应用的本体,它是将具体的业务处理逻辑编入程序中。而处理所需的数据则要从表示层或数据层取得。表示层和功能层之间的数据交互要尽可能简洁。
- 数据层:就是数据库管理系统,负责管理对数据库数据的读写。数据库管理系统必须能迅速执行大量数据的更新和检索。因此,一般从功能层传送到数据层的要求大都使用 SQL 语言。

解决方案:对这三层进行明确分割,并在逻辑上使其独立。原来的数据层作为数据库管理系统已经独立出来,所以,关键是要将表示层和功能层分离成各自独立的程序,并且还要使这两层间的接口简洁明了。一般情况下是只将表示层配置在客户机中,如果将功能层也放在客户机中,与二层 C/S 结构相比,其程序的可维护性要好得多,但是其他问题并未得到解决。客户机的负荷太重,其业务处理所需的数据要从服务器传给客户机,所以系统的性能容易变差。如果将功能层和数据层分别放在不同的服务器中,则服务器和服务器之间也要进行数据传送。但是,由于在这种形态中三层是分别放在各自不同的硬件系统上,所以灵活性很高,能够适应客户机数目的增加和处理负荷的变动。
B/S 架构风格
使用技术:B/S 结构主要是利用不断成熟的 WWW 浏览器技术,结合浏览器的多种脚本语言,用通用浏览器就实现了原本需要复杂的专用软件才能实现的强大功能,并节约了开发成本。

优点:基于 B/S 架构的软件,系统安装、修改和维护全在服务器端解决(零客户端),很容易在运行时自动升级。也可以更加充分利用网络上的各种资源,同时应用程序维护的工作量也大大减少。
不足:(1)B/S 架构缺乏对动态页面的支持能力,没有集成有效的数据库处理功能;
(2)采用 B/S 架构的应用架构,在数据查询等响应速度上,要远远地低于 C/S 架构;
(3)B/S 架构的数据提交一般以页面为单位,数据的动态交互性不抢,不利于在线事务处理(OnLine Transaction Processing,简称 OLTP )应用。
MVC架构风格
定义:全名是 Model ViewController,是模型(model)- 视图(view)- 控制器(controller)的缩写,分层架构的一种。
分工协作:
- Model 是对应用状态和业务功能的封装。Model 接受 Controller 的请求并完成响应的业务处理,在状态改变的时候向 View 发出相应的通知。
- View 实现可视化界面的呈现并捕捉最终用户的交互操作(例如鼠标和键盘的操作)。
- Controller 会根据需要控制原 View 或者创建新的 View 对用户交互操作予以响应。View 捕获到用户交互操作后直接转发给 Controller,后者完成相应的 UI 逻辑。如果需要涉及业务功能的调用,Controller 会直接调用 Model。

MVP架构风格
定义:全称为 Model-View-Presenter。MVP 是从MVC 演变而来。
与MVC的相同点:基本思想有相通的地方:Model 提供数据,View 负责显示,Controller/Presenter 负责逻辑的处理。
与MVC的不同点:MVC模式中元素之间“混乱”的交互主要体现在允许 View 和 Model 直接进行“交流”,这在MVP 中是不允许的。在 MVP 中 View 并不直接使用 Model,它们之间的通信是通过 Presenter (MVC中的Controller)来进行的,所有的交互都发生在Presenter 内部,而在 MVC 中 View 会直接从 Model 中读取数据而不是通过 Controller。
缺点:由于对视图的渲染放在了 Presenter 中,所以视图和 Presenter 的交互会过于频繁。还有一点需要明白,如果 Presenter 过多的渲染了视图,往往会使得它与特定的视图的联系过于紧密。一旦视图需要变更,那么 Presenter 也需要变更了。
优点:(1)模型与视图完全分离,我们可以修改视图而不影响模型;
(2)可以更高效的使用模型,因为所有的交互都发生在一个地方——Presenter 内部。
(3)我们可以将一个 Presenter 用于多个视图,而不需要改变 Presenter 的逻辑。这个特性非常的有用,因为视图的变化总是比模型的变化频繁;
(4)如果我们把逻辑放在 Presenter 中,那么我们就可以脱离用户接口来测试这些逻辑(单元测试)。
面向服务的架构(SOA)
典型的定义:(1)W3C 的定义:SOA 是一种应用程度架构,在这种架构中,所有功能都定义为独立的服务,这些服务带有定义明确的可调用接口,能够以定义好的顺序调用这些服务来形成业务流程。
(2)Service-architecture.com 的定义:服务是精确定义、封装完善、独立于其他服务所处环境和状态的函数。SOA 本质上是服务的集合,服务之间彼此通信,这种通信可能是简单的数据传送,也可能是两个或更多的服务协调进行某些活动。服务之间需要某些方法进行连接。
(3)Gartner 的定义: SOA 是一种 C/S 架构的软件设计方法,应用由服务和服务使用者组成,SOA 于大多数通用的 C/S 架构模型不同之处,在于它着重强调构件的松散耦合,并使用独立的标准接口。
**概述:**SOA是一种在计算环境中设计、开发、部署和管理离散逻辑单元(服务)模型的方法。由于 SOA 考虑到了系统内的对象,所以虽然 SOA 是基于对象的,但是作为一个整体,它却不是面向对象的。

服务的基本结构:

SOA 设计原则:
- 明确定义的接口
- 自包含和模块化
- 粗粒度
- 松耦合
- 互操作性、兼容和策略声明
SCA 服务构件于传统构件的区别:服务构件往往是粗粒度的,而传统构件以细粒度居多;服务架构的接口是标准的,主要是服务描述语言接口,而传统构件常以具体 API 形式出现;服务构件的实现与语言是无关的,而传统构件常绑定某种特定的语言;服务构件可以通过构件容器提供 QoS 的服务,而传统构件完全由程序代码直接控制。
**SOA 的关键技术:**这些技术都是以 XML 为基础而发展起来的。
| UDDI | 统一描述、发现和集成 | 数据模型;API;注册服务 |
| WSDL | Web 服务描述语言 | 服务实现定义包含:服务、端口;服务接口定义包含:绑定、端口类型、消息、类型 |
| SOAP | 简单对象访问协议 | 定义了服务请求和服务提供者之间的消息传输规范。SOAP包含:封装、编码规则、RPC表示、绑定。SOAP消息包含:封装(信封)、SOAP 头、SOAP体。 |
| REST | 表述性状态转移 | 是一种只使用 HTTP 和 XML 进行基于 Web 通信的技术,可以降低开发的复杂性,提高系统的可伸缩性。 |
SOA 的实现方法:
- Web Service

- 服务注册表
(1)服务注册
(2)服务位置
(3)服务绑定
- 企业服务总线(ESB)
内容:ESB 提供了一种基础设施,消除了服务请求者与服务提供者之间的直接连接,使得服务请求者和服务提供者进一步解耦。EJB 是由中间件技术实现并支持 SOA 的一组基础架构 ,是传统中间件技术于 XML、Web Service 等技术结合的产物,是在整个企业集成架构下的面向服务的企业应用集成机制。
功能:(1)支持异构环境中的服务、消息和基于事件的交互,并且具有适当的服务级别和可管理性;(2)通过使用 ESB ,可以在几乎不更改代码的情况下,以一种无缝的非侵入方式使现有系统具有全新的服务接口,并能够在部署环境中支持任何标准;(3)充当缓冲的 ESB 与服务逻辑相分离,从而使不同的系统可以同时使用同一个服务,不用在系统或数据发生变化时,改动服务代码;(4)在更高的层次,ESB 还提供诸如服务代理和协议转换等功能;(5)头攻可配置的消息转换翻译机制和基于消息内容的消息路由服务,传输消息到不同的目的地。
优势:(1)扩展的、基于标准的连接;(2)灵活的、服务导向的应用组合;(3)提高复用率,降低成本;(4)减少市场反应时间,提高生产率。
微服务
优势:(1)技术异构性;(2)弹性;(3)扩展;(4)简化部署;(5)与组织结构相匹配;(6)可组合型;(7)对可替代性的优化
挑战:(1)分布式系统的复杂度;(2)运维成本;(3)部署自动化;(4)DevOps 与组织结构;(5)服务间依赖测试;(6)服务间依赖管理
微服务与 SOA :

架构设计

软件架构文档化
内容: 一是过程,编档过程能促使架构设计师进一步思考,使得架构更加完善;二是结果,描述架构的文档将作为架构开发的成功,供项目关系人使用。
架构文档的使用者:架构的项目关系人。编写技术文档最基本的原则之一是要从读者的角度来编写。
编档规则:
- 从读者的角度编写文档
- 避免出现不必要的重复
- 避免歧义
- 使用标准结构
- 记录基本原理
- 使文档保持更新,但更新频率不要过高
- 针对目标的适应性对文档进行评审
视图编档:

软件架构评估
方法:
- 基于调查问卷或检查表的方式(依赖于评估人员的主观推断)
- 基于场景的方式:应用在架构权衡分析法(ATAM)和软件架构分析方法(SAAM)中。它是通过分析软件架构对场景的支持程度,从而判断该架构对这一场景所代表的质量需求的满足程度。
- 基于度量的方式:建立在软件架构度量的基础上
架构权衡分析法(ATAM)
步骤:


网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!
一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。**
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!
5630

被折叠的 条评论
为什么被折叠?



