Browsed by
标签:中间件

代码,到底该如何分层,才能给人赏心悦目的感觉?

代码,到底该如何分层,才能给人赏心悦目的感觉?

閱讀本文約花費: 8 (分鐘) # 背景 说起应用分层,大部分人都会认为这个不是很简单嘛 就controller,service, mapper三层。看起来简单,很多人其实并没有把他们职责划分开,在很多代码中,controller做的逻辑比service还多,service往往当成透传了,这其实是很多人开发代码都没有注意到的地方,反正功能也能用,至于放哪无所谓呗。这样往往造成后面代码无法复用,层级关系混乱,对后续代码的维护非常麻烦。 的确在这些人眼中分层只是一个形式,前辈们的代码这么写的,其他项目代码这么写的,那么我也这么跟着写。但是在真正的团队开发中每个人的习惯都不同,写出来的代码必然带着自己的标签,有的人习惯controller写大量的业务逻辑,有的人习惯在service中之间调用远程服务,这样就导致了每个人的开发代码风格完全不同,后续其他人修改的时候,一看,我靠这个人写的代码和我平常的习惯完全不同,修改的时候到底是按着自己以前的习惯改,还是跟着前辈们走,这又是个艰难的选择,选择一旦有偏差,你的后辈又维护你的代码的时候,恐怕就要骂人了。 所以一个好的应用分层需要具备以下几点: 方便后续代码进行维护扩展; 分层的效果需要让整个团队都接受; 各个层职责边界清晰。 # 如何进行分层 1、阿里规范 在阿里的编码规范中约束的分层如下: 开放接口层:可直接封装 Service 方法暴露成 …

Read More Read More

第十章 Seata–分布式事务

第十章 Seata–分布式事务

閱讀本文約花費: 19 (分鐘) 接上文,系列文章的最后一篇了,本文主要介绍了分布式事务的基础,场景,以及分布式事物的解决方案,最后对Seata进行了介绍。 10.1 分布式事务基础 10.1.1 事务 事务指的就是一个操作单元,在这个操作单元中的所有操作最终要保持一致的行为,要么所有操作都成功,要么所有的操作都被撤销。简单地说,事务提供一种“要么什么都不做,要么做全套”机制。 10.1.2 本地事物 本地事物其实可以认为是数据库提供的事务机制。说到数据库事务就不得不说,数据库事务中的 四大特性: A:原子性(Atomicity),一个事务中的所有操作,要么全部完成,要么全部不完成 C:一致性(Consistency),在一个事务执行之前和执行之后数据库都必须处于一致性状态 I:隔离性(Isolation),在并发环境中,当不同的事务同时操作相同的数据时,事务之间互不影响 D:持久性(Durability),指的是只要事务成功结束,它对数据库所做的更新就必须永久的保存下来 取大写首 字母 也就是 简称 ACID 数据库事务在实现时会将一次事务涉及的所有操作全部纳入到一个不可分割的执行单元,该执行单元中的所有操作要么都成功,要么都失败,只要其中任一操作执行失败,都将导致整个事务的回滚 10.1.3 分布式事务 分布式事务指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位…

Read More Read More

第七章 Rocketmq–消息驱动

第七章 Rocketmq–消息驱动

閱讀本文約花費: 16 (分鐘) 接上文,本文主要介绍了MQ是什么,及它的应用场景,消息发送和接收演示以及相关的案例。 7.1 MQ简介 7.1.1 什么是MQ MQ(Message Queue) 是一种跨进程的通信机制,用于传递消息。通俗点说,就是一个先进先出的数据结构。 7.1.2 MQ的应用场景 7.1.2.1 异步解耦 最常见的一个场景是用户注册后,需要发送注册邮件和短信通知,以告知用户注册成功。传统的做法如下: 此架构下注册、邮件、短信三个任务全部完成后,才返回注册结果到客户端,用户才能使用账号登录。但是对于用户来说,注册功能实际只需要注册系统存储用户的账户信息后,该用户便可以登录,而后续的注册短信和邮件不是即时需要关注的步骤。 所以实际当数据写入注册系统后,注册系统就可以把其他的操作放入对应的消息队列 MQ 中然后马上返回用户结果,由消息队列 MQ 异步地进行这些操作。架构图如下: 异步解耦是消息队列 MQ 的主要特点,主要目的是减少请求响应时间和解耦。主要的使用场景就是将比较耗时而且不需要即时(同步)返回结果的操作作为消息放入消息队列。同时,由于使用了消息队列MQ,只要保证消息格式不变,消息的发送方和接收方并不需要彼此联系,也不需要受对方的影响,即解耦合。 7.1.2.2 流量削峰 流量削峰也是消息队列 MQ 的常用场景,一般在秒杀或团队抢购(高并发)活动中使用广泛。…

Read More Read More

第一章 微服务的架构介绍发展

第一章 微服务的架构介绍发展

閱讀本文約花費: 16 (分鐘) 微服务架构, 简单的说就是将单体应用进一步拆分,拆分成更小的服务,每个服务都是一个可以独立运行的项目。那么下文主要了微服务架构的发展,详情请看下文。 微服务介绍 1.1 系统架构演变 随着互联网的发展,网站应用的规模也在不断的扩大,进而导致系统架构也在不断的进行变化。 从互联网早起到现在,系统架构大体经历了下面几个过程: 单体应用架构—>垂直应用架构—>分布 式架构—>SOA架构—>微服务架构,当然还有悄然兴起的Service Mesh(服务网格化)。 接下来我们就来了解一下每种系统架构是什么样子的, 以及各有什么优缺点。 1.1.1 单体应用架构 互联网早期,一般的网站应用流量较小,只需一个应用,将所有功能代码都部署在一起就可以,这 样可以减少开发、部署和维护的成本。 比如说一个电商系统,里面会包含很多用户管理,商品管理,订单管理,物流管理等等很多模块, 我们会把它们做成一个web项目,然后部署到一台tomcat服务器上。 优点: 项目架构简单,小型项目的话, 开发成本低 项目部署在一个节点上, 维护方便 缺点: 全部功能集成在一个工程中,对于大型项目来讲不易开发和维护 项目模块之间紧密耦合,单点容错率低 无法针对不同模块进行针对性优化和水平扩展 1.1.2 垂直应用架构 随着访问量的逐渐增大,单一应用只能依靠增加节点来应…

Read More Read More

Java微服务实践乱谈

Java微服务实践乱谈

閱讀本文約花費: 25 (分鐘) 楔子 目前业界最流行的微服务架构正在或者已被各种规模的互联网公司广泛接受和认可,业已成为互联网开发人员必备技术。无论是互联网、云计算还是大数据,Java平台已成为全栈的生态体系,其重要性几乎不可替代。 这两年微服务作为一个非常新的技术,各种理论流派试图从不同的角度去阐述其概念和优势,我一开始是拒绝的,因为我没有”Duang“的一下想清楚。个人感性地认知是,姿势不对,纯靠意会。理性的看法则是,在思想上,那些布道师们并未达到一致。经过参考各家思想之后,得到了一些自己的领悟,我分享给大家。 微服务是什么? 微服务是一种细粒度(Fine-Grain)的SOA 个人认为,与其说微服务是一种技术,不如将其定义为一种架构,而架构则是“技”的实现与“术”的策略相辅相成。“术”的策略需要分析使用场景,进行合理地划分业务边界,实现“业以类聚”,然而“技”的实现则通过特定的技术在实现业务逻辑之时,更多的考虑实现过程中的效率性、测试的便利性、维护的可持续性,达到“技以群分”的目的。 由此而论,我个人偏好将其定义为:“微服务是一种细粒度的SOA”。 这样定义的好处在于,没必要去重复地“抹黑”“单体应用”(Monolithic,也有人翻译成“巨石应用”),缘于SOA技术的衍化过程中早已提及。那么,细粒度更多的体现在“取其精华,去其糟粕”。 SOA又是什么? SOA = Ser…

Read More Read More

阿里玄难:面向不确定性的软件设计几点思考

阿里玄难:面向不确定性的软件设计几点思考

閱讀本文約花費: 19 (分鐘) 在纷繁复杂的业务发展中,变化已成为了唯一的不变。如何保障基础设施的安全、高可用性,同时提供高效的创新支持?今天,阿里副总裁、业务平台事业部掌门人玄难,结合阿里巴巴业务平台建设和个人多年大型软件设计经验,提炼成几点思考,希望对大家的软件架构设计有所启发。 玄难 阿里副总裁 业务平台事业部掌门人 特别说明:本文中所说的软件都指代面向最终用户的偏业务的软件,不包含操作系统、中间件等系统软件。 1、软件发展的几个阶段 软件工具和信息化阶段:软件最早是为了数值计算,以工具的形态出现的。包括PC时代我们非常熟悉的Excel,Word这些好东西。以及典型的企业内部管理的信息系统,例如:企业流程审批、进销存管理系统等等。互联网服务阶段:随着PC互联网兴起,淘宝、QQ、Google、新浪这些全新的互联网服务逐步进入了我们的日常生活。社会基础设施阶段:随着移动互联网、IOT、人工智能的出现和高速发展,各种各样的软件进入社会经济生活的方方面面,软件之间相互连接,构成了一个纷繁复杂的生态系统,变成了不可或缺的社会基础设施。 随着软件形态的变化,过去非常高效的系统架构和组织形态遇到了全面的挑战。因为我们所处的环境已经从量变到质变,突破临界点,产生了本质的不同。 阿里巴巴就是这个过程中的典型代表。从过去单一的电商业务演变成了复杂的经济体,没有了确定性的业务边界,蓬勃发展的业务…

Read More Read More

阿里云ACP考试认证心得+须知

阿里云ACP考试认证心得+须知

閱讀本文約花費: 8 (分鐘) 一、 简介 阿里云针对不同产品类别、用户行业、用户成长阶段,精心打造不同的认证考试。 二、 阿里云认证体系 助理工程师(ACA),Alibaba Cloud Certified Associate获得此认证,证明您可以进行阿里云基础产品的使用和管理; 认证工程师(ACP),Alibaba Cloud Certified Professional获得此认证,证明您可以基于阿里云产品解决企业的基本业务问题; 认证高级工程师(ACE),Alibaba Cloud Certified Expert获得此认证,证明您可以基于阿里云产品进行架构设计并解决业务发展中的主要问题。 ACP认证目前又按专业方向分四种 云计算(主要对应阿里云基础架构产品)、 大数据(主要对应阿里云大数据系列产品)、 云安全(主要对应阿里云云盾系列产品)、 企业级互联网架构(主要对应阿里云企业级中间件系列产品)。 目前主流的认证是阿里云云计算ACP认证,适用范围最广、考试难度较小,是面向使用阿里云云计算产品的架构、开发、运维人员的专业技术认证。大数据、安全、企业级互联网架构,这三个各侧重于一个方向,适合该方向的从业者考取。 三、 考前购买须知(下面以阿里云云计算ACP专业认证为例) 1.去云市场购买阿里云云计算ACP专业认证考试授权码,目前的云计算ACP价格为1200元,ACE价格为192…

Read More Read More

面试官:你知道java类是怎么跑起来的吗?问的我一脸懵

面试官:你知道java类是怎么跑起来的吗?问的我一脸懵

閱讀本文約花費: 15 (分鐘) 类从加载虚拟机内存中开始到卸载出内存为止,生命周期包括:加载、验证、准备、解析、初始化、使用、卸载。 加载、验证、准备、初始化和卸载这5个阶段的顺序是确定的,类的加载过程必须按照这种顺序进行,而解析阶段则不一定,它在某些情况下可能在初始化阶段后在开始,因为java支持运行时绑定。 加载阶段 通过一个类的全限定名来获取定义此类的二进制字节流(没有指明二进制字节流要从一个Class文件中获取,可以从ZIP包中读取,从网络中获取,运行时计算生成等等) 然后,将这个字节流所代表的静态储存结构转化为方法区的运行时数据结构在内存中生成一个代表这个类的java.lang.Class对象,也就是说,当程序中使用任何类时,系统都会为之建立一个java.lang.Class对象。 该Class对象作为方法区这个类的各种数据的访问入口完成后,虚拟机外部的二进制字节流就按照虚拟机所需格式储存在方法区中。 这里稍微理解一下对象和类的概念,对象是实例化的类。类的信息是存储在方法区中的,对象是存储在Java堆中的。类是对象的模板,对象是类的实例。 类的加载由类加载器完成,类加载器通常由JVM提供,这些类加载器也是前面所有程序运行的基础,JVM提供的这些类加载器通常被称为系统类加载器。除此之外,开发者可以通过继承ClassLoader基类来创建自己的类加载器。 其实加载阶段用一句…

Read More Read More

软件架构设计-五视图方法论(2)

软件架构设计-五视图方法论(2)

閱讀本文約花費: 8 (分鐘) 1.每个人都可以做成为架构设计师 不懂软件的和刚入行的人们一听到架构设计,都认为是非常的高大上课题,是一个遥不可及的领域,一般人是不能做的。听起来云里雾里的,第一印象除了来自微软,阿里这些NB的公司里面的人其余的都不能做出架构似的,这是一种先入为主的思想,因为大家都在强调架构师的重要性,他的薪资有多么的高,在整个社会对他的认定导致很多人对架构设计望而生畏。放正自己的心态其实架构设计并没有多么的复杂。我们是从编码入行的,在编码实现功能的过程中我们或多或少的设计了属于自己的软件架构了。为什么说软件架构师需要多少年的工作经验,因为软件架构就是系统的草图,不仅是代码编写而且包括部署,运行、开发等这些方面进行设计,目的是为了保证软件开发、运行、扩展、性能、安全、伸缩等等质量的一个保证。只要在编码过程中不仅仅要提升编码的质量而且要留心其他方面的知识积累与学习,用不了多久你也能成为一位优秀的架构设计师。 2.什么是架构设计 我们要成为架构设计师我们需要了解什么是架构设计。简单一点,架构设计就是一个系统的草图,描述了构成系统的抽象组件,以及各个组件之间的是如何进行通讯的,这些组件在实现过程中可以被细化为实际的组件比如类或者对象。在面向对象领域中,组件之间的联通通常面向于接口实现的。在“软件架构简介”中David Garlan 和Mary Shaw 认为软件架构师有关…

Read More Read More

软件架构设计-五视图方法论

软件架构设计-五视图方法论

閱讀本文約花費: 12 (分鐘) 在实际工作中,我们经常听到“架构”和“架构师”这样的名词,并不新鲜,但是总让很多刚入门的 ​​​在实际工作中,我们经常听到“架构”和“架构师”这样的名词,并不新鲜,但是总让很多刚入门的人感觉很神秘,甚至是高深莫测。很少有人对“架构”有全面的了解和认识能并说清楚架构是什么,更谈不上掌握了。事实上,也只有极少数人能成为或者被冠以“架构师”这样的title。为此,笔者总结了对架构的一些理解,希望能够补充很多初入门的人在这方面认识上的不足,纠正一些误解。高手和老鸟就直接跳过吧。 架构的分类 对于“架构”来讲,理论上划分了5种架构视图,分别是:逻辑架构、开发架构、运行架构、物理架构、数据架构。根据名字,大家都可能大概能猜到其侧重点和含义。这里先用通俗的文字简单介绍下,便于大家理解,大家可以不必纠结概念和这些理论。 逻辑架构:逻辑架构关注的是功能,包含用户直接可见的功能,还有系统中隐含的功能。或者更加通俗来描述,逻辑架构更偏向我们日常所理解的“分层”,把一个项目分为“表示层、业务逻辑层、数据访问层”这样经典的“三层架构”。 开发架构:开发架构则更关注程序包,不仅仅是我们自己写的程序,还包括应用程序依赖的SDK、第三方类库、中间价等。尤其是像目前主流的Java、.NET等依靠虚拟机的语言和平台,以及主流的基于数据库的应用,都会比较关注。和逻辑架构有紧密的关联。 …

Read More Read More