系统搭建初期,为对公司业务进行快速支持,每每搭建的系统很是加单,主要为了知足快速迭代的需求,使用公司初期的高速发展。 随着业务的愈来愈繁杂,系统会变得愈来愈复杂,除了须要在技术角度去知足系统的高性能,稳定性,高可用等需求外,设计能够知足业务需求迭代的架构一样重要。程序员
为快速支撑复杂业务能力,系统代码每每采用类中写几千行代码,一个方法中处处if-else,若是再没有阅读性好的代码和注释,随着员工离职,接手的程序员很难快速介入代码进行开发,反过来则限制了系统业务能力的快速迭代。 最坏的结果可能形成由于愈来愈难以迭代,使得系统推翻重作。spring
系统初期每每采用三层架构方式搭建,上层为controller,中间层为service,下层的数据访问为dao层。数据库
Controller编程
Controller层每每推荐只做请求参数和响应参数的处理等一些浅逻辑,好比协议转换等。数组
业务代码中,每每按照业务领域划分和组织代码结构,好比按照订单,会员等划分,这样一样能够在Controller层作好请求到领域内的映射。缓存
好比:架构
主要的原则是:网关内对协议进行处理,将业务逻辑进行收敛,不暴漏给外部,这样在内部逻辑进行重构时,不须要外界感知变化。异步
Service分布式
业务层是承载业务流程和业务规则的地方,一样能够采用分层方式进行代码逻辑组织:性能
业务服务层
业务服务层能够做为按业务领域划分的领域对外的接口,每一个接口表明一个领域业务,好比订单领域内逻辑统一放在Order Service,帐户领域交给User Service。
在接口指责划分上,能够采用读写接口分离的原则,好比:Order Read Service和Order Write Service,这样在将来系统在技术角度须要作读写分离处理和流量管理时,能够减小极大的梳理成本。
接口中功能方法的名称尽可能有意义,好比订单建立叫作cereate Order,取消订单叫作 cancel Order,而不是简单的增删改查名称。
参数组织上如:Request,DO,DTO等。
业务流程层
业务流程表明对于规则的解释和梳理,规则是将PM的需求翻译成代码的过程,因此一样能够经过多种标准化动做进行控制:
主要原则是将容易变更的地方作到易修改,易测试,减小新功能迭代时的理解成本。 将不易变更的功能进行拆分,固化,变成可维护的业务组件。
业务组件层
业务组件层是将一些可服用的逻辑,可固化的功能进行内聚封装,能够有参数组件,规则判断组件,动做行为组件等。
业务组件的造成每每是在对业务理解深入以后演进出来的,过早的抽象每每效果很差。
组件内聚以后可能产生如:短信组件,下单组件扽。
多种组件能够组合产生业务流程的能力。
Dao
数据访问层一样能够由两部分组成:接口定义,技术组件。
接口定义
底层数据能力须要和上层业务能力分离,经过设计合理的接口,向业务层屏蔽底层复杂度。 能够基于面向接口编程的思想设计数据库访问接口和缓存访问接口等。
技术组件
系统随着业务发展和须要承载的用户愈来愈多,须要经历单机,集群,服务化等多个阶段,因此须要沉淀下来一些技术组件,来将多个阶段问题进行固化封装,达到系统发展而业务无需感知的能力。 能够沉淀的技术组件包括:数据存储,缓存,消息,调度任务,事务,锁机制等。
数据存储,底层能够封装访问关系数据库,日志系统HBase,文件系统HDFS,本地文件系统等。
缓存,能够按照不一样的超时时间纬度或数据量进行选择,好比本地内存的Encache,集中式缓存Memcache,集中式可持久化的Redis集群等,同时能够将缓存击穿处理等逻辑进行集成。
消息,在系统中经常用来解决异步处理能力,消息的消费每每和调度任务组合起来,能够按照调度规则,配置一次或者屡次业务逻辑的处理。
事务,每每采用数据库实现,单机的事务依赖于数据库事务,可使用spring-tx的事务进行事务控制,业务逻辑中,事务应该尽可能小,能够将业务逻辑紧密的数据库操做放在一块儿。在分布式场景下能够根据不一样的业务需求选择不一样的分布式事务处理机制。
锁,主要有两种:乐观锁和悲观锁。
经过以上方式咱们能够提炼出针对于业务系统所须要具有的通用能力,在必定程度上知足了业务系统规则易变的特色,固然不一样业务场景有本身的要求,很难有银弹,还须要根据本身的业务场景进行提炼和补充。