1. 分层架构(垂直)
-
@H_301_3@分层架构是最基础的,即很久之前就接触的mvc,当然书里说的是基础设施层,领域层,服务层,用户接口层;
@H_301_3@因这种架构各层之间极易耦合,即顶层依赖底层教严重;就引入DI(depency inverse)原则,使得各层之间不再相互依赖实现,而是依赖接口,实现了解耦;抽象不依赖于细节,细节依赖于抽象;
@H_301_3@DI原则的引用,各层之间上下界限不在明显;可以看成平面的六角形;
2. 六边形架构(平面)
-
@H_301_3@六边形是平面的架构,其核心是端口和适配器;
@H_301_3@将前端和后端的概念延伸为系统外部区域和系统内部区域
@H_301_3@端口处理输入或处理输出,适配器将输入或输出适配到API中;
@H_301_3@端口可提供各种通信协议,如rest,http,soap,AMQP协议;
@H_301_3@适配器用于调用API,且可以提供各种具体的实现形式;
@H_301_3@目前大部分使用spring的架构都是六边形架构(使用ioc);
3. 面向服务架构 (SOA) service-Oriented architecture,其设计原则如下:
-
@H_301_3@服务契约 通过契约文档进行描述
@H_301_3@松耦合 服务将依赖关系最小化
@H_301_3@服务抽象 隐藏内部实现
@H_301_3@服务重用性 可以被其他服务所重用
@H_301_3@服务自治性 服务自行控制环境和资源保持独立性,
@H_301_3@服务无状态性 服务负责消费方的状态管理
@H_301_3@服务可发现性 客户可以通过服务元素就来查找服务
@H_301_3@服务组合性 一种服务可以由其他服务组合而成
@H_301_3@使用soa设计时在于确定服务的界限上下文,不能为soa而SOA;
@H_301_3@在ddd中,业务价值大于战术策略,战略目标大于项目利益;在soa实施中,多考虑业务和战略 4. rest风格
@H_301_3@rest Represential State Transfer 表现层状态转化
@H_301_3@包含http的动作:get,put,post,delete,patch
@H_301_3@get 获取资源查询结果,安全,幂等;可缓存
@H_301_3@put 覆盖资源进行更新,非安全,幂等(idempotent)
@H_301_3@post 新建资源,非幂等
@H_301_3@delete 删除操作,幂等
@H_301_3@patch 局部更新,幂等
@H_301_3@数据交换格式大体为xml或json;一般用json
@H_301_3@使用HATEOAS(hymedia as the engine of application service)技术,可以返回相关资源的链接;
@H_301_3@该架构风格具有良好的松耦合性和可扩展性
5. CQRS(读写分离command-query responsibility sgregation )
-
@H_301_3@紧缩(Stringent)对象设计原则和命令-查询分离(CQRS)原则共同应用的结果
@H_301_3@系统中一部分专门负责数据的command命令,另一部分负责query;
@H_301_3@分为读模型和命令模型;读模型可以新建若干具体的视图,针对不同的需求进行查询;
@H_301_3@命令处理器(Command Processor):处理接受命令.有三种风格:分类风格,专属风格,消息风格
@H_301_3@分类风格(categorized style) 一个服务中不同的方法处理不同类型的命令
@H_301_3@专属风格(dedicated style) 每个处理器只有一个单独的方法,单独的类处理单独的命令
@H_301_3@消息风格(messaging style) 专属风格的异步用法
@H_301_3@事件订阅器 用来更新查询模型
@H_301_3@查询结果是否同步 大部分是做不到同步;有三种方法:1.命令结束,修改缓存数据;2.记录查询模型的最新时间,命令操作后自动触发时间更新,然数据不是最新的可以发出提醒;3.直接通知数据已被处理,但还需要一段时间才能查看结果; 6. 事件驱动架构(Event-Driven Architecture,EDA)
@H_301_3@基于管道和过滤器风格(pipe,filter) 6.1. 基于消息的管道和过滤器处理过程的基本特征
@H_301_3@管道是消息通道
@H_301_3@端口连接过滤器和通道
@H_301_3@过滤器既是处理器 可以对消息进行处理
@H_301_3@分离处理器 每个过滤处理器都是一个分离的组件
@H_301_3@松耦合 每个过滤处理器都是单独的参与处理,处理器组合通过配置完成
@H_301_3@可换性 位置组合科幻
@H_301_3@过滤器可以使用多个管道 并行处理
@H_301_3@同种类型的过滤器可以并行运行
-通过消息处理组件订阅上游的事件,处理之后,发布本身的事件,下游的消息处理组件将订阅它; 7. 长时处理过程(Long-Running Process) 7.1. 长时处理过程的设计方法
-
@H_301_3@将处理过程设计成一个组合任务,使用一个执行组件对任务进行跟踪,对各个步骤和任务完成情况进行持久化
@H_301_3@将处理过程设计为聚合,这些聚合在一系列的活动中相互协作.一个或多个聚合实例充当执行组件并维护整个处理过程的状态
@H_301_3@设计一个无状态的处理过程,其中每一个处理组件都将对所接受到的信息进行扩充--即向其中加入额外的数据信息--然后将消息发送给下一个处理组件;整个处理过程的状态包含在每条信息中 7.2. 执行器和跟踪器
@H_301_3@每个长时处理过程的状态实例
@H_301_3@如何处理系统中消息的重复投递: 1.查看该事件中的相应的状态属性,如果状态已被设值,执行器会忽略该事件并对该事件作出应答; 2.将状态对象设置为幂等,执行后消息不会产生其他改变.
@H_301_3@执行时间校验;被动校验和主动校验;
@H_301_3@被动校验:完成事件到达时执行;通过调用hasTimedOut()方进行判断;风险:1.事件未完成,未触发而没超时;
@H_301_3@主动校验:外部的定时器来校验.比如JMX的TimerMBean实例,创建一个定时监听器.缺点,需要更多的系统资源,可能会增加系统的运行负担;