Browsed by
标签:APP

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

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

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

Read More Read More

SpringCloud Alibaba——服务注册与发现(Nacos)

SpringCloud Alibaba——服务注册与发现(Nacos)

閱讀本文約花費: 5 (分鐘) 一、Nacos简介 Nacos致力于帮助您发现、配置和管理微服务。Nacos提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据及流量管理。Nacos帮助您更敏捷和容易地构建、交付和管理微服务平台。Nacos是构建以“服务”为中心的现代应用架构 (例如微服务范式、云原生范式) 的服务基础设施。 安装Nacos 下载地址(版本:0.7.0) Linux:sh startup.sh? Windows:startup.cmd? 访问:http://127.0.0.1:8848/nacos,可以进入Nacos的服务管理页面: 二、SpringCloud整合Nacos 完成了Nacos服务的安装和启动之后,下面就可以编写两个应用(服务提供者与服务消费者)来验证服务的注册与发现了。 spring cloud的版本以及spring cloud alibaba的版本,由于spring cloud alibaba还未纳入spring cloud的主版本管理中,所以需要自己加入,添加依赖文件(父工程): <properties><java.version>1.8</java.version><spring-cloud.version>Finchley.RELEASE</spring-cloud…

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

第九章 Nacos Config–服务配置

第九章 Nacos Config–服务配置

閱讀本文約花費: 8 (分鐘) 本文介绍微服务架构下关于配置文件的一些问题,Nacos Config入门及深入,nacos的几个概念等,更多请看下文。 9.1 服务配置中心介绍 首先我们来看一下,微服务架构下关于配置文件的一些问题: 配置文件相对分散。在一个微服务架构下,配置文件会随着微服务的增多变的越来越多,而且分散在各个微服务中,不好统一配置和管理。 配置文件无法区分环境。微服务项目可能会有多个环境,例如:测试环境、预发布环境、生产环境。每一个环境所使用的配置理论上都是不同的,一旦需要修改,就需要我们去各个微服务下手动 维护,这比较困难。 配置文件无法实时更新。我们修改了配置文件之后,必须重新启动微服务才能使配置生效,这对一 个正在运行的项目来说是非常不友好的。 基于上面这些问题,我们就需要配置中心的加入来解决这些问题。 配置中心的思路是: 首先把项目中各种配置全部都放到一个集中的地方进行统一管理,并提供一套标准的接口。 当各个服务需要获取配置的时候,就来配置中心的接口拉取自己的配置。 当配置中心中的各种参数有更新的时候,也能通知到各个服务实时的过来同步最新的信息,使之动态更新。 当加入了服务配置中心之后,我们的系统架构图会变成下面这样: 在业界常见的服务配置中心,有下面这些: Apollo Apollo是由携程开源的分布式配置中心。特点有很多,比如:配置更新之后可以实时生效,…

Read More Read More

由12306.CN谈谈网站性能技术

由12306.CN谈谈网站性能技术

閱讀本文約花費: 31 (分鐘) 12306.cn网站挂了,被全国人民骂了。我这两天也在思考这个事,我想以这个事来粗略地和大家讨论一下网站性能的问题。因为仓促,而且完全基于本人有限的经验和了解,所以,如果有什么问题还请大家一起讨论和指正。(这又是一篇长文,只讨论性能问题,不讨论那些UI,用户体验,或是是否把支付和购票下单环节分开的功能性的东西) 业务 任何技术都离不开业务需求,所以,要说明性能问题,首先还是想先说说业务问题。 其一,有人可能把这个东西和QQ或是网游相比。但我觉得这两者是不一样的,网游和QQ在线或是登录时访问的更多的是用户自己的数据,而订票系统访问的是中心的票量数据,这是不一样的。不要觉得网游或是QQ能行你就以为这是一样的。网游和QQ 的后端负载相对于电子商务的系统还是简单。其二,有人说春节期间订火车的这个事好像网站的秒杀活动。的确很相似,但是如果你的思考不在表面的话,你会发现这也有些不一样。火车票这个事,一方面会伴随着大量的查询操作,更BT的是下单的时候需要对数据库很多的一致性的操作,一方面是从起点到终点各个分段票的一致性,另一方面,买的人路线、车次、时间选择有很多,会不停地改变下单方式。而秒杀,直接杀就好了,没有那么多查询和一致性的问题。另外,关于秒杀,完全可以做成只接受前N个用户的请求(完全不操作后端的任何数据, 仅仅只是对用户的下单操作log),这种业务,只需…

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