html业务网站源码,新乡专业网站建设公司,网站怎么自己做,做网站还是自媒体更适合赚钱一般初创软件#xff0c;为快速上线#xff0c;几乎不考虑分层。但随业务越发复杂#xff0c;就会导致逻辑复杂、模块相互依赖、代码扩展性差等各种问题。 架构分层迫在眉睫。 1 什么是架构分层? 软件工程中常见的设计方式#xff0c;将整体系统拆分成N个层次#xff0c;… 一般初创软件为快速上线几乎不考虑分层。但随业务越发复杂就会导致逻辑复杂、模块相互依赖、代码扩展性差等各种问题。 架构分层迫在眉睫。 1 什么是架构分层? 软件工程中常见的设计方式将整体系统拆分成N个层次每个层次有独立的职责多个层次协同提供完整的功能。 初学 JavaWeb 时一般要求设计成 MVC 架构。另外一种常见的分层方式是将整体架构分为 表现层Web 展示数据结果和接受用户指令的是最靠近用户的一层 逻辑层Service 复杂业务的具体实现 数据访问层Dao 主要处理和存储之间的交互。 这就可以隔离关注点让不同的层专注做不同的事情。其它分层案例比如OSI网络七层模型TCP/IP协议网络四层模型。 2 分层有什么好处 简化设计 各司专职而不必将自己活成全才。 高复用 比如在设计某系统时发现某层具有通用性就可把它抽取独立出来在设计其它系统时使用。 横向扩展 可以让我们更容易做横向扩展。如果系统没有分层当流量增加时我们需要针对整体系统来做扩展。但是如果我们按照上面提到的三层架构将系统分层后就可以针对具体的问题来做细致的扩展。 比如业务逻辑里面包含有比较复杂的计算导致CPU成为性能的瓶颈那这样就可以把逻辑层单独抽取出来独立部署然后只对逻辑层来做扩展这相比于针对整体系统扩展所付出的代价就要小的多了。 架构分层究竟和高并发设计的关系是怎样的?我们知道横向扩展是高并发设计思想之一既然架构分层可方便横向扩展 那么高并发系统一定是分层的。 3 如何架构分层 关键在于理清层次边界。 若按三层架构分层边界不就很容易界定吗 是的没毛病当业务逻辑简单时层次间边界的确清晰开发新功能时也知道把代码往哪写。但当业务逻辑越来越复杂边界也会变得模糊。 3.1 案例 任一系统都有用户模块比如返回用户信息的接口它调用逻辑层的GetUser方法GetUser方法又和User DB交互获取数据就像下图左边展示的样子。 这时产品提出一个需求在APP中展示用户信息的时候若用户不存在那么要自动给用户创建一个用户。同时要做一个HTML5页面保留之前的逻辑即不需要创建用户。这时逻辑层的边界就变得不清晰表现层也承担了一部分的业务逻辑将获取用户和创建用户接口关联。 3.2 主流分层职责 MVC架构的简单性让太多的人觉得项目工程结构理所应当就是这样的然后呢一大堆的业务逻辑就随意的堆砌在了service中对象啥的只是单纯的数据传输作用出现了用面向对象的语言写面向过程的程序的普遍现象。按照领域驱动设计的思路最重要的还要有领域模型层。当然manage层这种方案也是一种思路但是我觉得这种方式还不够必须有清晰的业务模型和合理的分层结构配合才能更好的提现分层的作用。 终端显示层 各端模板渲染并执行显示的层。当前主要是 Velocity/framemaker渲染、js渲染、移动端展示等 开放接口层 将Service层方法封装成开放接口同时进行网关安全控制和流量控制等 Web层 主要是对访问控制进行转发各类基本参数校验或者不复用的业务简单处理等 Service层 业务逻辑层。调用manager层和dao层处理业务即简单的业务可以不抽取manager直接调用dao。 业务类的校验放在service层一般性的参数校验可以放在web层这可以通用化。 Manager 层通用业务处理层 DDD中也叫领域层。 可以将原先Service层的一些通用能力下沉到这一层比如与缓存和存储交互策略中间件的接入。业务逻辑放在managerservice来编排manager的原子服务。 也可在这一层封装对第三方接口的调用比如调用支付服务调用审核服务等 该分层架构相比MVC主要就是增加了Manager层它与Service层的关系Manager层提供原子的服务接口Service层负责依据业务逻辑来编排原子接口。 业务逻辑就是你的产品逻辑比如创建用户要具体做什么。 manager层的原子服务指的是实现单一功能的服务。 事务应该在service层 DAO层数据持久层 数据访问层与底层 MySQL、Oracle、HBase 等进行数据交互。缓存可以放在存储层。 外部接口或第三方平台 包括其它部门 RPC 开放接口基础平台其它公司的 HTTP 接口 例如Manager层提供创建用户和获取用户信息的接口Service层负责将这两个接口组装起来。这样就把原先散布在表现层的业务逻辑都统一至Service层每层边界就清晰了。 比如做一个接口可将实现放在service层。之后公司内部调用逻辑可放在web层。而哪一天公司要开放这个接口可直接新抽象一层(一个新的服务)即开放平台层这样的好处是可以将本司使用和第三方使用做隔离。比如在提供服务时为了保证自家接口性能对开放平台层做限流处理。 传统公司很多是分层部署的比如保险和金融。service和dao部署在比较严密的网络区域controller层部署在一个较宽松的网络区域对外提供服务。等于在网络上增加了一个缓冲区来保证服务的安全而且可以通过单向网络规范层级调用controller可以调用服务层而服务层是不能调用web层的。 如果将数据访问层单独部署比如拆分为单独的rpc服务当然这样拆分粒度比较细。controller就是对外的门面调用单独的服务层 可以为后期服务运维降低成本 可以提高数据访问层的复用度数据访问层对外提供API其他层的应用通过API方式与数据库进行交互三来可以屏蔽各个数据库实现的具体细节。 3.3 层间依赖 数据流转只能在相邻层间。以三层架构为例数据从表示层进入后一定要流转到逻辑层做业务逻辑处理然后流转到数据访问层和DB交互。但若业务逻辑很简单可否从表示层直接到数据访问层甚至直接读DB 功能上是可以的但从长远架构设计考虑这会造成层级调用混乱比如一旦DB地址变更就需更改多层这就失去了分层价值且维护或重构都是灾难。 4 架构分层的缺陷 4.1 增加代码复杂度 原本可在接收请求后直接查询DB获得结果却非要在中间多层设计每层只简单地做数据传递。 有时增加一个小需求可能还需更改所有层的代码增加了开发成本也增加了调试复杂度增加了与其它模块负责人的沟通成本。 4.2 性能损耗 若每层独立部署层间通过网络交互那多层架构势必会在性能上有所损耗。 那是否还要选择架构分层呢肯定的。 你要知道任何的方案架构都是有优势有缺陷的天地尚且不全何况我们的架构呢分层架构固然会增加系统复杂度也可能会有性能的损耗但是相比于它能带给我们的好处来说这些都是可以接受的或者可以通过其它的方案解决的。我们在做决策的时候切不可以偏概全因噎废食。 5 总结 分层架构是软件设计思想的外在体现是一种实现方式。一些软件设计原则都在分层架构中有所体现。 比方单一职责原则规定每个类只有单一的功能在这里可引申为每层拥有单一职责且层与层之间边界清晰 迪米特法则原意是一个对象应当对其它对象尽可能少的了解在分层架构的体现是数据的交互不能跨层只能在相邻层之间进行 开闭原则要求软件对扩展开放对修改关闭。它的含义其实就是将抽象层和实现层分离抽象层是对实现层共有特征的归纳总结不可修改但具体实现可无限扩展随意替换。 参考 《阿里巴巴Java开发手册》 本文由 mdnice 多平台发布
