Browsed by
标签:Java

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

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

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

Read More Read More

团队间差异大,如何统一估算基准?

团队间差异大,如何统一估算基准?

閱讀本文約花費: 9 (分鐘) 实施规模化敏捷时,组织管理多个Scrum团队时将面临更多的挑战。如果您已让多个团队工作于同一个项目,那么协作会变得更复杂,特别是估算的时候。 这些团队需要进行估算和制定计划,并基于计划来跟踪进度,以便PO能安排其工作优先顺序,在有成果物交付时与干系人进行交流。 但多个Scrum团队共同工作会带来更多的挑战,包括: 团队技能和经验水平都不同时,该如何处理?怎样才能在无需每位团队成员都参与的情况下准确估算工作?在不知道该由哪个团队来承接工作的情况下,怎样完成估算? 我将与大家分享一个解决方案。但在此之前,让我们先来看看大多数组织在为多个Scrum团队做估算时都会犯的两个关键错误。   错误1:估算不能反映所有团队的能力 第一个错误往往发生在公司挑选一组人员来估算整个待办项时。这本身并不是一个坏主意(事实上稍后我会建议您这么做)。与让大团队每个人都参与每个待办项的估算相比,这样么做当然会更快、更高效。并且或许您还会认为,只要选择的人员合适,估算结果就会是富有见地的。 但这正是事情容易出错的地方,因为一旦缺乏熟悉即将开展的工作且能真正代表所有Scrum团队的人员,您就会得到基于非常片面和不准确的视角而生成的估算值。 不幸的是,目前许多公司正在发生这样的事情:估算数据由那些脱节于即将开展的工作及其实施团队的人员创建。 这样做的结果之一是:得…

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

第六章 Sleuth–链路追踪

第六章 Sleuth–链路追踪

閱讀本文約花費: 11 (分鐘) 本文介绍微服务架构中最重要的设计模式:微服务之间的数据通讯。更多请看全文。 6.1 链路追踪介绍 在大型系统的微服务化构建中,一个系统被拆分成了许多模块。这些模块负责不同的功能,组合成系统,最终可以提供丰富的功能。在这种架构中,一次请求往往需要涉及到多个服务。 互联网应用构建在不同的软件模块集上,这些软件模块,有可能是由不同的团队开发、可能使用不同的编程语言来实现、有可能布在了几千台服务器,横跨多个不同的数据中心,也就意味着这种架构形式也会存在一些问题 于是就出现了下面几个 问题 如何快速发现问题? 如何判断故障影响范围? 如何梳理服务依赖以及依赖的合理性? 如何分析链路性能问题以及实时容量规划? 分布式链路追踪(Distributed Tracing),就是将一次分布式请求还原成调用链路,进行日志记录,性能监控并将一次分布式请求的调用情况集中展示。比如各个服务节点上的耗时、请求具体到达哪 台机器上、每个服务节点的请求状态等等。 常见的链路追踪技术有下面这些: cat 由大众点评开源,基于Java开发的实时应用监控平台,包括实时应用监控,业务监控 。 集成方案是通过代码埋点的方式来实现监控,比如: 拦截器,过滤器等。 对代码的侵入性很大,集成成本较高。风险较大。 zipkin 由Twitter公司开源,开放源代码分布式的跟踪系统,用于收集服务的定时…

Read More Read More

第五章 Gateway–服务网关

第五章 Gateway–服务网关

閱讀本文約花費: 15 (分鐘) 接上一篇文章开始网关之旅,首先告诉大家网关是什么,Gateway简介,怎么配置,怎么入门,执行流程等等相关介绍。 大家都都知道在微服务架构中,一个系统会被拆分为很多个微服务。那么作为客户端要如何去调用 这么多的微服务呢?如果没有网关的存在,我们只能在客户端记录每个微服务的地址,然后分别去 用。 这样的架构,会存在着诸多的问题: 客户端多次请求不同的微服务,增加客户端代码或配置编写的复杂性 认证复杂,每个服务都需要独立认证。 存在跨域请求,在一定场景下处理相对复杂。 上面的这些问题可以借助API网关来解决。 所谓的API网关,就是指系统的统一入口,它封装了应用程序的内部结构,为客户端提供统一服务,一些与业务本身功能无关的公共逻辑可以在这里实现,诸如认证、鉴权、监控、路由转发等等。 添加上API网关之后,系统的架构图变成了如下所示: 我们也可以观察下,我们现在的整体架构图: 在业界比较流行的网关,有下面这些: Ngnix+lua 使用nginx的反向代理和负载均衡可实现对api服务器的负载均衡及高可用 lua是一种脚本语言,可以来编写一些简单的逻辑, nginx支持lua脚本 Kong 基于Nginx+Lua开发,性能高,稳定,有多个可用的插件(限流、鉴权等等)可以开箱即用。问题: 只支持Http协议;二次开发,自由扩展困难;提供管理API,缺乏更易用…

Read More Read More

第四章 Sentinel–服务容错

第四章 Sentinel–服务容错

閱讀本文約花費: 30 (分鐘) 从高并发带来的问题的问题说起 ,讲解服务雪崩效应,常见容错方案,Sentinel基础,相关的应用规则等。 4.1 高并发带来的问题 在微服务架构中,我们将业务拆分成一个个的服务,服务与服务之间可以相互调用,但是由于网络原因或者自身的原因,服务并不能保证服务的100%可用,如果单个服务出现问题,调用这个服务就会出现网络延迟,此时若有大量的网络涌入,会形成任务堆积,最终导致服务瘫痪。 接下来,我们来模拟一个高并发的场景 @[email protected] class OrderController2 {@Autowiredprivate OrderService orderService;@Autowiredprivate ProductService productService;@RequestMapping(“/order/prod/{pid}”)public Order order(@PathVariable(“pid”) Integer pid) {log.info(“接收到{}号商品的下单请求,接下来调用商品微服务查询此商品信息”, pid); //调用商品微服务,查询商品信息Product product = productService.find…

Read More Read More

如何超过大多数人

如何超过大多数人

閱讀本文約花費: 23 (分鐘) 当你看到这篇文章的标题,你一定对这篇文章产生了巨大的兴趣,因为你的潜意识在告诉你,这是一本人生的“武林秘籍”,而且还是左耳朵写的,一定有干货满满,只要读完,一定可以练就神功并找到超过大多数人的快车道和捷径……然而…… 当你看到我这样开篇时,你一定会觉得我马上就要有个转折,告诉你这是不可能的,一切都需要付出和努力……然而,你错了,这篇文章还真就是一篇“秘籍”,只要你把这些“秘籍”用起来,你就一定可以超过大多数人。而且,这篇文章只有我这个“人生导师”可以写得好。毕竟,我的生命过到了十六进制2B的年纪,踏入这个社会已超过20年,舍我其谁呢?! P.S. 这篇文章借鉴于《如何写出无法维护的代码》一文的风格……嘿嘿 相关技巧和最佳实践 要超过别人其实还是比较简单的,尤其在今天的中国,更是简单。因为,你只看看中国的互联网,你就会发现,他们基本上全部都是在消费大众,让大众变得更为地愚蠢和傻瓜。所以,在今天的中国,你基本上不用做什么,只需要不使用中国互联网,你就很自然地超过大多数人了。当然,如果你还想跟他们彻底拉开,甩他们几个身位,把别人打到底层,下面的这些“技巧”你要多多了解一下。 在信息获取上,你要不断地向大众鼓吹下面的这些事: 让大家都用百度搜索引擎查找信息,订阅微信公众号或是到知乎上学习知识……要做到这一步,你就需要把“百度一下”挂在嘴边,然后要经常在群或…

Read More Read More

第二章 微服务环境搭建

第二章 微服务环境搭建

閱讀本文約花費: 5 (分鐘) 本次是使用的电商项目中的商品、订单、用户为案例进行讲解。本章只是搭建基本环境,并不过多讲解. 2.1 案例准备 2.1.1 技术选型 maven:3.6.0 数据库:MySQL 5.7 持久层: SpingData Jpa 其他: SpringCloud Alibaba 技术栈 2.1.2 模块设计 下面是项目端口号说明及项目结构 springcloud-alibaba 父工程 shop-common公共模块【实体类】 shop-user用户微服务 【端口: 807x】 shop-product商品微服务 【端口: 808x】 shop-order订单微服务 【端口: 809x】 2.1.3 微服务调用 在微服务架构中,最常见的场景就是微服务之间的相互调用。我们以电商系统中常见的用户下单为例来演示微服务的调用:客户向订单微服务发起一个下单的请求,在进行保存订单之前需要调用商品微服务查询商品的信息。 我们一般把服务的主动调用方称为服务消费者,把服务的被调用方称为服务提供者。 在这种场景下,订单微服务就是一个服务消费者, 商品微服务就是一个服务提供者。 2.2 创建父工程 创建一个maven工程,然后在pom.xml文件中添加下面内容 截自 2020 年 1月 7日 版本对应: 2.3 创建基础模块 1 创建shop-common 模块,在pom.xml…

Read More Read More

如何写出无法维护的代码

如何写出无法维护的代码

閱讀本文約花費: 17 (分鐘) 酷壳里有很多我觉得很不错的文章,但是访问量最大的却是那篇《6个变态的Hello World》,和它能在本站右边栏“全站热门”中出现的还有“如何加密源代码”,以及编程真难啊等这样的文章。可见本站的读者们的偏好,我也相信你们都是“身怀绝技”的程序员。所以,今天给大家推荐这篇文章,相信一定能触动大家的兴奋点。 这篇文章的原文在这里(http://mindprod.com/jgloss/unmain.html),我看完后我想说—— 什么叫“创造力”,创造力就是——就算是要干一件烂事都能干得那么漂亮那么有创意的能力。什么叫“抓狂”,抓狂就是——以一种沉着老练的不屈不挠的一本正经的精神一点一点把你推向崩溃的边缘。 我把文章节选了一些,也并没有完全翻译,简译一下,也加入了一些自己的调侃。对于有下面这些编程习惯的朋友,请大家对号入座。另外,维护程序的朋友们,你们死定了!! If builders built buildings the way programmers write programs, then the first woodpecker that came along would destroy civilization. (如果建筑师盖房子就像程序员写程序一样,那么,第一只到来的啄木鸟就能毁掉我们的文明)~ Gerald Weinberg&…

Read More Read More

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

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

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

Read More Read More