Browsed by
标签:架构

敏捷过程中如何保证代码质量

敏捷过程中如何保证代码质量

閱讀本文約花費: 10 (分鐘)本文目录: 一、为什么要做代码质量分析 二、常见的代码质量分析工具 三、DevOps平台中的代码质量分析 四、DevOps平台中如何为代码质量提供保障 一、为什么要做代码质量分析 在软件开发过程中,当一个功能开发完成后,如何去保证代码是可用的、没问题的?一般情况下,基本都会有单元测试、每日构建、功能测试等环节来保证。但是,保证代码可用就够了吗?显然不是。 一个软件项目开发完一个版本会有下一个版本,会有新的需求,原来的功能也可能会变更。你写的代码可能会被别人使用,你也可能需要修改别人写的代码。如果只考虑代码的可用性,不考虑代码质量,那么后期遇到的问题其维护成本将会很高,不利于版本迭代。为了避免或减少维护和迭代成本,重视代码质量,做好代码质量分析和管控是最好的方式。 二、常见的代码质量分析工具 既然要做代码质量分析,那我们先看看常用的代码分析工具。 PMD: 注重检查源文件中的潜在问题,可以检查Java代码中是否有未使用的变量、私有方法,是否有空的try/catch、是否过于复杂的表达式等等。 CheckStyle:注重代码格式、代码规范,通过检查编码格式、命名约定、Javadoc、类设计等方面进行代码规范和风格的检查,从而有效约束开发人员更好地遵循代码编写规范,提供常见IDE的插件,如eclipse,IDEA等。 FindBugs:注重检测潜在的Bug…

Read More Read More

分布式事务问题的几种方案

分布式事务问题的几种方案

閱讀本文約花費: 8 (分鐘)分布式事务的实现主要有以下 5 种方案: XA 方案 TCC 方案 本地消息表 可靠消息最终一致性方案 最大努力通知方案 两阶段提交方案/XA方案 所谓的 XA 方案,即:两阶段提交,有一个事务管理器的概念,负责协调多个数据库(资源管理器)的事务,事务管理器先问问各个数据库你准备好了吗?如果每个数据库都回复 ok,那么就正式提交事务,在各个数据库上执行操作;如果任何其中一个数据库回答不 ok,那么就回滚事务。 这种分布式事务方案,比较适合单块应用里,跨多个库的分布式事务,而且因为严重依赖于数据库层面来搞定复杂的事务,效率很低,绝对不适合高并发的场景。如果要玩儿,那么基于 Spring+JTA 就可以搞定,自己随便搜个 demo 看看就知道了。 对于这个方案,一般来说某个系统内部如果出现跨多个库的这么一个操作,是不合规的。我可以给大家介绍一下, 现在微服务,一个大的系统分成几十个甚至几百个服务。一般来说,我们的规定和规范,是要求每个服务只能操作自己对应的一个数据库。 如果你要操作别的服务对应的库,不允许直连别的服务的库,违反微服务架构的规范,你随便交叉胡乱访问,几百个服务的话,全体乱套,这样的一套服务是没法管理的,没法治理的,可能会出现数据被别人改错,自己的库被别人写挂等情况。 如果你要操作别人的服务的库,你必须是通过调用别的服务的接口来实现,绝对不允许…

Read More Read More

再有人问你分布式事务,把这篇扔给他

再有人问你分布式事务,把这篇扔给他

閱讀本文約花費: 24 (分鐘)前言 不知道你是否遇到过这样的情况,去小卖铺买东西,付了钱,但是店主因为处理了一些其他事,居然忘记你付了钱,又叫你重新付。又或者在网上购物明明已经扣款,但是却告诉我没有发生交易。这一系列情况都是因为没有事务导致的。这说明了事务在生活中的一些重要性。有了事务,你去小卖铺买东西,那就是一手交钱一手交货。有了事务,你去网上购物,扣款即产生订单交易。 事务的具体定义 事务提供一种机制将一个活动涉及的所有操作纳入到一个不可分割的执行单元,组成事务的所有操作只有在所有操作均能正常执行的情况下方能提交,只要其中任一操作执行失败,都将导致整个事务的回滚。简单地说,事务提供一种“要么什么都不做,要么做全套(All or Nothing)”机制。 数据库本地事务 ACID 说到数据库事务就不得不说,数据库事务中的四大特性,ACID: A:原子性(Atomicity) 一个事务(transaction)中的所有操作,要么全部完成,要么全部不完成,不会结束在中间某个环节。事务在执行过程中发生错误,会被回滚(Rollback)到事务开始前的状态,就像这个事务从来没有执行过一样。 就像你买东西要么交钱收货一起都执行,要么要是发不出货,就退钱。 C:一致性(Consistency) 事务的一致性指的是在一个事务执行之前和执行之后数据库都必须处于一致性状态。如果事务成功地完成,那么…

Read More Read More

常用的分布式事务解决方案

常用的分布式事务解决方案

閱讀本文約花費: 46 (分鐘)众所周知,数据库能实现本地事务,也就是在同一个数据库中,你可以允许一组操作要么全都正确执行,要么全都不执行。这里特别强调了本地事务,也就是目前的数据库只能支持同一个数据库中的事务。但现在的系统往往采用微服务架构,业务系统拥有独立的数据库,因此就出现了跨多个数据库的事务需求,这种事务即为“分布式事务”。那么在目前数据库不支持跨库事务的情况下,我们应该如何实现分布式事务呢?本文首先会为大家梳理分布式事务的基本概念和理论基础,然后介绍几种目前常用的分布式事务解决方案。废话不多说,那就开始吧~ 什么是事务? 事务由一组操作构成,我们希望这组操作能够全部正确执行,如果这一组操作中的任意一个步骤发生错误,那么就需要回滚之前已经完成的操作。也就是同一个事务中的所有操作,要么全都正确执行,要么全都不要执行。 事务的四大特性 ACID 说到事务,就不得不提一下事务著名的四大特性。 原子性 原子性要求,事务是一个不可分割的执行单元,事务中的所有操作要么全都执行,要么全都不执行。 一致性 一致性要求,事务在开始前和结束后,数据库的完整性约束没有被破坏。 隔离性 事务的执行是相互独立的,它们不会相互干扰,一个事务不会看到另一个正在运行过程中的事务的数据。 持久性 持久性要求,一个事务完成之后,事务的执行结果必须是持久化保存的。即使数据库发生崩溃,在数据库恢复后事务提交的结果…

Read More Read More

浅谈服务治理与微服务

浅谈服务治理与微服务

閱讀本文約花費: 12 (分鐘)近期都在谈微服务,本人也正在做相关的工作,应领导要求做了一个微服务的分享,本篇文章主要来源于分享的PPT,所以有些简单,有问题可以在下面留言,大家 一起讨论。 本篇文章先简单介绍了互联网架构的演变,进而介绍了服务化,最后再介绍微服务,微服务是服务治理的升级也是互联网架构的进一步延伸。 互联网架构演变 一体架构 在计算机软件发展早期,一般桌面软件都是采用这种架构,不管是界面还是业务处理还是数据处理都放到一个包中。这种其实谈不上架构,但也可以说是很好的架构,因为它足够简单。 mvc架构 但随着浏览器的出现便产生了web应用,web应用的特点是界面部分是显示在浏览器中,服务处理是在服务容器中的,页面显示一般用css+js+html技术来处理,而后端可以用java、php等语言,这就产生了前后端分离。对于web系统,一体架构难以满足前后端分离的开发需求,因而便产生了MVC架构。 MVC才算的上真正意义上的架构,因为它除了解决了前后端分离问题,还引入了一种全新的开发模式,用一种业务逻辑、数据、界面显示分离的方法组织代码,使得整个应用层次更加分明,而且各个层次之间不但减低了耦合性,还提高了各个层次的可重用性。 但随着应用规模的不断扩大,应用模块不断增加,整个应用也显得越来越臃肿,维护起来也更加困难,因此便又产生了多应用架构。 多应用架构 多应用架构很简单,就是把…

Read More Read More

苹果放弃英特尔芯片,为什么会打击美国计算机产业?

苹果放弃英特尔芯片,为什么会打击美国计算机产业?

閱讀本文約花費: 16 (分鐘)今年6月22日,苹果公司在一年一度的全球开发者大会 WWDC 上,宣布彻底放弃英特尔公司(Intel)的 CPU,改用自己设计的 ARM 芯片。 上一篇文章已经分析过了,苹果为什么要这样做。主要原因是,整个苹果战略是围绕移动端(iPhone)构建的,它现在想把移动端和桌面端合成一个生态,自己完全控制所有硬件和软件,不愿再让 CPU 这样的核心部件受制于英特尔了。 今天接着往下谈,这个”换芯”决定有什么后果。 表面上看,这是苹果公司的”家务事”,但是实际上牵动各方的利益,产生一系列的连锁反应,动摇长久以来主导行业的 Wintel 联盟,甚至会影响到美国的竞争优势。 一、英特尔的反应 苹果宣布换芯以后,英特尔仅仅发了一个简短的声明。 “苹果公司与我们有多个业务领域的合作,我们将继续为他们提供支持。……我们相信,基于 Intel 的 PC 将为全球客户提供最佳的体验。” 言下之意,这只是一件小事,不用大惊小怪。市场似乎也同意这种观点,英特尔股价当天小幅下跌,没过几天又涨回去了。 为什么英特尔觉得影响不大? 因为它的利润主要来自服务器 CPU,2019年占到利润总额的一半。个人电脑 CPU 的利润只占到三分之一,而 MacOS 只占全世界桌面操作系统市场的17%,…

Read More Read More

苹果电脑为什么要换 CPU:Intel 与 ARM 的战争

苹果电脑为什么要换 CPU:Intel 与 ARM 的战争

閱讀本文約花費: 12 (分鐘)三个月前,新款 iPad Pro 发布,支持触摸板和鼠标。 上图的黑点就是鼠标。苹果公司显然打算,平板电脑当作笔记本使用。 我们知道,iPad 的操作系统跟 iPhone 是一样的,都是基于 iOS。如果 iOS 可以用于笔记本,就意味着可以跟桌面系统 MacOS 统一了。如果 MacBook 和 iPhone 都用同一个操作系统,App 就能通用了。 苹果公司显然也是这么打算的。几天后的6月22日将举行 WWDC(苹果全球开发者大会)。媒体报道,苹果公司将在那一天宣布,更换 Mac 电脑的 CPU,从 Intel 公司的 x86 架构改成 ARM 架构。 一旦 Mac 跟 iPhone 使用同样架构的 CPU,那就铺平了统一操作系统的道路。操作系统无法通用的最主要原因,就是 CPU 架构不同。 本文回顾苹果公司的 CPU 架构变化历史,帮助大家理解这件事的技术含义,以及未来的影响。 一、CPU 架构是什么 CPU 的全称是”中央处理单元”,它是计算机的核心,计算都由它来完成。但是,CPU 本身只是一个概念,每家芯片公司都有自己的具体实现。 不同的 CPU 设计实现,就称为” CPU 架构”(CPU architecture)。 不同的 CPU 架构有不同的指令集,彼此不通用,这导致运行在上面…

Read More Read More

微服务部署:蓝绿部署、滚动部署、灰度发布、金丝雀发布

微服务部署:蓝绿部署、滚动部署、灰度发布、金丝雀发布

閱讀本文約花費: 7 (分鐘) 在项目迭代的过程中,不可避免需要”上线“。上线对应着部署,或者重新部署;部署对应着修改;修改则意味着风险。 目前有很多用于部署的技术,有的简单,有的复杂;有的得停机,有的不需要停机即可完成部署。本文的目的就是将目前常用的布署方案做一个总结。 一、蓝绿布署 Blue/Green Deployment(蓝绿部署) 1、定义 蓝绿部署是不停老版本,部署新版本然后进行测试,确认OK,将流量切到新版本,然后老版本同时也升级到新版本。 1、特点 蓝绿部署无需停机,并且风险较小。 2、布署过程 第一步、部署版本1的应用(一开始的状态) 所有外部请求的流量都打到这个版本上。 image.png 第二步、部署版本2的应用 版本2的代码与版本1不同(新功能、Bug修复等)。 第三步、将流量从版本1切换到版本2。 image.png 第四步、如版本2测试正常,就删除版本1正在使用的资源(例如实例),从此正式用版本2。 3、小结 从过程不难发现,在部署的过程中,我们的应用始终在线。并且,新版本上线的过程中,并没有修改老版本的任何内容,在部署期间,老版本的状态不受影响。这样风险很小,并且,只要老版本的资源不被删除,理论上,我们可以在任何时间回滚到老版本。 4、蓝绿发布的注意事项 当你切换到蓝色环境时,需要妥当处理未完成的业务和新的业务。如果你的数据库后端无法处理,会是一个比较…

Read More Read More

部署策略对比:蓝绿部署、金丝雀发布及其他

部署策略对比:蓝绿部署、金丝雀发布及其他

閱讀本文約花費: 13 (分鐘)目前,软件开发最大的变化是部署频率。产品团队更早(更频繁)的将产品发布到生产环境。数月或者数年的发布周期变得越来越短 – 对那些构建纯软件产品的人来说更是如此。 现在,使用面向服务的架构和微服务方式,开发者可以设计模块化的代码库。这允许他们同时在代码库中不同的地方编写和部署代变更。 缩短部署周期的业务优势狠明显: 缩短上市时间 客户可以在更短的时间内获得产品价值 客户的反馈也会更快的到达产品团队,这意味着团队可以更快的迭代特性和修复问题 开发人员的整体士气会上升 但是,这种转变也给运维或者 DevOps 团队带来了新挑战。更频繁的部署,意味着已经部署的代码会对站点可用性和客户体验带来负面影响。这就是制定代码部署策略如此重要的原因,因为它可以最大限度的降低产品和客户的风险。 在本文中,我们将讨论不同的部署策略、最佳实践和工具,让你的团队可以更快更可靠的工作。 现代应用的挑战 现代应用通常是分布式的,基于云的。它们可以弹性扩展来满足需求,基于高可用架构更好地容错。这些应用可以使用全托管服务,例如 AWS Lambda 和 Elastic Container Service(ECS) 等平台处理一些运维责任。 这些应用经常频繁部署。例如,移动 app 和 web 应用可能一个月内经历多次更改。有些甚至一天…

Read More Read More

Kubernetes 下日志采集、存储与处理技术实践

Kubernetes 下日志采集、存储与处理技术实践

閱讀本文約花費: 25 (分鐘) 本文介绍了“Logtail + 日志服务 + 生态”架构,介绍了:Logtail客户端在Kubernetes日志采集场景下的优势. 日志服务作为基础设施一站式解决实时读写、HTAP两大日志强需求;日志服务数据的开放性以及与云产品、开源社区相结合,在实时计算、可视化、采集上为用户提供的丰富选择。 Kubernetes日志处理的趋势与挑战 Kubernetes的serveless化 Kubernetes容器技术促进了技术栈的去耦合,通过引入栈的分层使得开发者可以更加关注自身的应用程序和业务场景。从Kubernetes本身来看,这个技术解耦也在更进一步发展,容器化的一个发展的趋势是:这些容器都将会在无服务器的基础设施上运行。 谈到基础设施,首先可以联想到云,目前在AWS、阿里云、Azure的云上都提供了无服务器化的Kubernetes服务。在serverless Kubernetes上,我们将不再关心集群与机器,只需要声明容器的镜像、CPU、内存、对外服务方式就可以启动应用。 如上图,左右两边分别是经典Kubernetes、serverless Kubernetes的形态。在从左向右发展的过程中,日志采集也变得复杂: 1.在一个Kubernetes node上,可能会运行更大规模量级的pod,每个pod上都可能有日志或监控指标采集需求,意味着单node上…

Read More Read More