超威半导体

背景介绍为了长期持续高质量、高效率的迭代，必须遵守一定的研发规范，其中主要包括静态代码的扫描和单元测试两个部分。风险认知行业的普遍共识，风险识别暴露的越晚，修复的成本越高。好代码不是一蹴而就的，是持续重构出来的目标技术选型最佳实践安装sonarLint本地IntelliJ IDEA安装sonarlint，根据提示重启IntelliJ IDEA即可有两个选项：根据本地修改扫描和全量扫描。可以根据实际情况开启。扫描结果如下：此处扫描出范型约束丢失的可能运行时异常，风险等级为M

问题很多APP为了引流营销创造除了各种玩法，其中红包雨就是常见的一种方式，主要效果就是预告在某个时间点，会发布多少金额的券等等，到点就能够聚集上百万用户来抢，大概效果就是疯狂的戳屏幕，然后偶现几个金额，最后结束后告诉一共抢到xx元。这里面有两个挑战。1. 如何扛住这种高并发流量2. 如何保证不超卖。主要思路业务真实意图很多技术方案挑战很大，可以从业务的角度去进行优化，换个思路可能技术挑战就不大了，例如抢购用户数是固定吗？一定要把所有金额分发出去么？如果是固定，那我们可以前置，不用在活动的时候

背景最近一个开发的朋友开始学习Java，她之前写脚本语言多一点，对于面向对象的一些设计还是不够熟练，她写一个代码特别的累，需要大量堆if-else语句，她的直觉告诉她这样写肯定不够好，然后咨询了我。场景介绍她的代码逻辑是要处理一个BinlogDTO的Message消息，然后做一些后续的逻辑，由于前面的设计是很多张表都会沿用这个BinlogDTO对象并且发送的一个Message的Topic，这个BinlogDTO的对象大概定义为：class BinlogDTO { private String

题目现在有个游戏，有过亿的用户会来玩，玩游戏后会获得一个分数，当游戏结束的时候返回给用户自己所在的排名和排名前百分比，如何设计这样一个系统。思路功能其实并不算复杂，有很多种方式可以实现，所以这就要明确整个系统需要支持的用户量和容错与扩展等等，例如如果这个就几百的并发。方案1 mysql直接搞一个mysql的表即可解决。user_score (id, user_id, score, create_time)，游戏结束就insert一条记录，然后select count出分数比自己高的，然后再coun

建造者模式，目的就是把复杂对象的内部组装流程和组建的具体表示给解耦。就如同中国宝马汽车制造流水线，流程都一样，只是每一个流程使用的具体品牌或则规格不太一样，现在就可以制造出来3系，5系等等不同的车，哪天工厂升级了，来个7系的生产，流程差不多，主要就是升级了更好的配件。其实没必要严格的按照标准的类图去设计，例如我认为其中导演类我就认为没必要，可以封装在要创建的对象内部。还是以我说制造汽车的例子，过了3年我再来重写，我会这样：class BMWCar { /** * 系列 */

背景库存是电商中的一个核心概念，主要记录商品的可售等数量信息，其既简单又复杂，简单是因为它大多数时候就是提供一个商品是否可售的信息，下单扣库存，退款或则入库加库存就行了，因此从业务的角度上的确不算复杂。为什么复杂？因为在分布式高并发库存的性能上来说是需要考虑很多的，由此而展开的一系列的优化又会使简单的业务操作变的实现上异常复杂。本文介绍接触到一些库存上的优化，也会参照业界的最佳实践与设计模式探讨...

不好意思最近实在是有点太忙了，将近一个月没更新博客，其实前几天我是有发表一篇关于HSF框架的源码解析，后来由于一些原因不得不删除。其实HSF也跟Dubbo类似，解决了分布式系统中的一系列问题。分布式带来的优势就是能够将复杂业务拆分成多个服务的组合，就如同controller-service-dao中的service接口部署在不同的机器上，service不就是服务的抽象么。让不同的团队维护不同的ser

我是主攻后端的开发人员，但是项目人手紧缺，我的经历刚好是做过node.js后端，所以我们前后端的分离工作就交到我的头上来了，这次我们采用node.js。前端的使用和后端果然还是很多不同的。node.js在系统中处的作用我的理解就是分离前后端，后端更多提供一个数据服务，传统的后端可能就是MVC，在我看来C就是控制器，主要的工作就是在参数的校验和数据与视图的整合。这个部分是可以交给前端去做的，让后端与视

最近做一个功能，需要在整个服务器容器加载完成就触发执行，这个时候我只需要实现ApplicationListener即可。spring的这个接口就是给一个观察的入口，可以在各个阶段去触发相应的操作。不难看出这就是典型的设计模式之观察者模式。这次我们以观察者的观点去分析一下ApplicationListener。/** * Interface to be implemented by applicat

上一篇博客写了用AOP去完成参数校验的功能，但是作为一个比较通用的解决方案，如果要添加新的校验规则，最好是不需要修改原有的代码。前一篇博客在注解里把校验规则给写死了，这是不灵活的。拦截到了请求之后我们可以定制具体的校验方案。想想之前学的设计模式之策略模式不就是在一系列相同步骤当中封装了容易变化的部分么。因此这次我们采用策略模式来设计校验工具。 首先定义一个策略接口：最开始的思路是这样的，用一个拦截

自从计算机诞生以来，生产效率大大的提高，尤其是微型计算机能够进入千家万户。让大众能够利用强大的计算资源，但是单纯的计算机硬件虽然能够提供机械强大的计算能力，但是要有效的利用这样的能力就需要用软件去操作，就像不同国家的人说着不同的语言，我们需要通过翻译才能够顺利沟通，同样计算机也需要明白人类需要它做什么事情，所以计算机对应的语言就叫做机器语言即一般来说的二进制编码。这是一种跟人类语言相差很大的语言，虽

好久没更新设计模式系列的文章了，最近工作有些变动，无论如何都不能停止学习。在产品中发挥更大的价值。设计模式一直是我非常重视的一块内容，如果说数据结构算法是编程的内功，那设计模式就是架构师的内功。 中介者模式是行为模式的一种，它主要是封装了通信的关心的复杂性，如果很多同事之间都有消息的传递。这个时候如果再增加新的同事，那通信开销会成倍增加。 扩展的困难性导致我们想到可以用一个中介类类维护这种复

背景介绍互联网公司与传统公司的信息化一个很大的不同就是架构更加偏向分布式，并非这个比较高级或则是某个人的偏好，而是由于业务基因所决定，因为传统公司往往需求是明确的，开发结束就能够长期稳定运行，互联网公司就不一样，大多都是从一个小的产品迭代而来，需求往往不明确，所以像传统公司按照需求来评估硬件资源变的不现实，分布式开发开辟了另一个横向扩展 scale out的思路用分布式集群达到提供强大服务的方式。

我总喜欢隔一段时间就来学习学习设计模式，每当业务代码写得感觉有点累的时候就喜欢考虑一下是否可以优化一下结构，尤其是当写到重复性的代码，总想着把它复用起来，一种情况是在开发之前就设计好可复用的模块，另一种是被动的在项目当中写到重复的代码的时候再去考虑代码的重构达到良好的复用。而复用的两种方式主要是继承和组合，当然在大部分情况下，设计原则指引我们更多采用组合的方式，其实各有各的优势，继承有更明确的类之间

前言：上一篇提到了关于并发编程的学习计划，计划赶不上变化，最近在熟悉新的业务，其实也学习到很多先进的供应链相关的东西，但是很多可能比较敏感不太方便放到博客上来，所以关于并发编程这块东西得过阵子才能更新，很久没更新设计模式相关的东西了，这次来谈谈我对桥梁模式的理解吧。模式描述：桥梁模式是结构型设计模式，它解决的问题就是多维度多变化的类爆炸性问题，意思就是很多对象是多个维度去组合，我们不需要把这种组

最近又看了一波设计模式的东西，又有一些新的认识，设计模式一般是重构到模式，模式不是一蹴而就的，很多最开始在实现产品经理的需求时，第一版是不太能识别模式的，当然如果后期的迭代需求方向明确也可做提前设计，因为对业务不够了解，对模式的学习最基本的是需要识别稳定点和变化的点。1.假设系统全部都是无变化的，那设计模式就是无意义的。 2.如果系统各个部分都是变化的，那没有任何模式可以解决问题。从...

最近做了一些技改，由于本次618大促我作为稳定性负责人，梳理了大量系统稳定性相关的功能，平时疲于业务的迭代很多系统性的问题在大促前才梳理出来，本问也沉淀一下关于稳定性这块自己的心得。 订单量的增加可能导致一些并发的问题，这块需要做好并发的控制，单机可以使用JUC提供的锁控制，现在集群一般采取redis等高可用的分布式缓存去做分布式锁，但是一般采取DB做分布式锁可靠性更高。 DB的优化也是重...

测试是一个很大的话题，每个研发团队都在强调测试的重要性，在不同的阶段测试的价值也是不一样的，每个研发团队都或多或少有自己的测试“文化”。在很多时候忽视了对测试环节的重视，导致的稳定性差而增加更多的工作量是得不偿失的，应该系统性的认识测试的价值，并好好规划。我也是参考了很多文章，自己总结了一些现在的情况基本概念单元测试：本地测试，非IO和RPC调用，可以本地单独测试，比较复杂的业务逻...

在高并发的系统中关于缓存的重要性不言而喻，缓存在项目当中大量使用，扛住了大部分的查询流量，但也有很多点需要注意，最为典型的例子就是数据一致性问题，缓存击穿问题，缓存高可用问题等等。这次需要解决的问题是一个秒杀场景的高并发问题。关于缓存一致性问题缓存一致性就是说DB的数据与缓存的数据保持一致，理论上同一瞬间去变更两个值是最理想的，访问缓存跟DB是一致的，但是在分布式的情况下，无论如何操作，更新D...

代理模式分为静态代理和动态代理，关于动态代理参考我前一篇文章静态代理 但是静态代理的问题就是灵活性不太好，我可能需要动态的改变被代理的类，这样可以增加扩展性和灵活性。依赖java反射在运行期间确定到底由具体的实现类去实现完成代理者的调用功能。 这里解耦了代理者也被代理之间的耦合性，可以动态的选择需要代理的类，这样可以大大增加系统的可扩展性，利用了大量的反射虽然灵活性达到了，但是反射

责任链模式是一种行为模式,很多时候我们对象在处理一个请求的条件是比较灵活的,可能代码中存在大量的if-else结构,不同条件的处理逻辑可能比较复杂,可能会使一个类过分的复杂,或者可能不符合类的单一原则,而且对于处理方式的改变也很可能会涉及到原有代码的改变,责任链模式就是解决这样一种应用场景的可能.责任链的UML图 主要由三个角色组成:Handler : 责任链的基础,维护Handler的引用,类似

最近团队需要给团队讲解设计模式，这次我来聊聊代理模式。首先我们先来回顾设计模式的意义和面向对象可复用设计的六大原则。 代理模式 很多时候我们无法直接访问到对象，但是在业务中又需要操作该对象。或则是代码在执行过程中部分生成的对象是需要耗费大量资源的，但是我们并不是每次都需要生成这些对象，或则是我们要访问某个对象我们需要做一些额外功能的添加或则是要控制权限，这我们都可以用代理模式去做。 代理，就

我们最开始设计系统的时候，根据面向对象的原则，我们会让各个类实现单一原则，或则设计的比较分散，外观模式就是将各个相对独立的子系统集成起来向客户端提供一个简单的接口去调用，这样隐藏了一系列操作的实现细节，降低了系统的复杂度，这也符合了面向对象的开闭原则。 举一个电脑启动的例子：public class Demo { public static void main(String[] arg

设计模式不拘泥于语言，不拘泥于特定的场景，传达的是一种思想，在实际学习中我们或多或少的接触所谓的设计模式的名字，为了学设计模式也不得不去看很多样例，因为抽象的思想很难表达，而语言是能够具体表达的东西，无论如何，我们最后设计出的目标都是要复合面向对象几大基本原则的。开闭原则接口隔离依赖倒置里氏替换单一职责最小知识面向接口编程与尽量用组合去替换继承关系复用 满足这些原则的OOA被公认为是

数据库产品这么多，归根到底还是为了更好的存储，集中管理，与数据共享，另外还有高可用，高性能，容错性等等。 上一篇文章最后介绍了Redis，作为一种内存数据库，它的应用十分的广泛，它存储的是一种K-V结构的记录。学习一个数据库首先抓住重点就是学会如何使用增删改查，这次来演示下如何Java构建Redis的增删改查。Redis的集群还有工作原理暂时不做探讨。 1首先去Redis官网下载Redis官网

jetty是一个web容器，由Java编写，谷歌前阵子从tomcat迁移到了google让外界开始注意jetty。其实jetty作为一个出色web容器，的确有部分的优势是应用最广的apache tomcat所不具备的。 jetty更容易去定制，tomcat是一个比较重量级的web容器，大部分的时候其实很多模块我们并不需要去使用，但是我们没太多可定制的余地，jetty给我们一个可以定制的方式，谷歌的

有很久没谈关于设计模式的内容了，这次我想来谈谈新的看法。 在这里我还想再次啰嗦两句设计的原则：开闭原则，依赖倒置，接口隔离，里氏替换原则，最小知识，单一职责。 还有几个规范：面向接口编程是稳定的架构，能使用组合尽量不使用继承来关联，重写破坏了对象的封装性破坏了开闭原则。 关于设计模式，没有特定的规范，这只是一种思想，同一种设计模式可能演变出很多类似的变种，这个时候死板硬套并不

代理模式属于经典的设计模式，这次在学习spring的时候学习到aop的相关会应用到代理的模式，因此深入学习代理模式。代理模式的UML图:这里也体现了面相接口编程，我们在客户端定义接口，然后可以通过使用代理去完成相关操作。这样我们可以延迟实际干活的类的加载时间，也可以灵活的让代理去选择具体调用哪个实际干活的类，这样屏蔽了客户端需要知道的细节，也可以方便的去扩充实际被调用的类，增加了扩展性。我们很多

学习模式是一个漫长的过程，应该明确的认识到设计模式的意义在哪里，我们学起来才会更加具有针对性，而不是为了设计模式而设计模式。最近看到一段话感觉挺有意思的： 计算机的强大在于它不知道疲倦，他的计算力持久性和准确性是人类无法抗衡的，它不知道疲倦，你永远不要想着靠蛮力或则逻辑简单重复性的工作战争计算机。但是电脑有缺点吗？有！因为人类创造了计算机，创造力是计算机短时间内的最大短板，虽然谷歌的alphago

软件就是现实世界的抽象，最近经过一些重构不断的认识到封装变化，接口隔离，开闭原则，针对接口编程，能使用组合尽量不使用继承的设计原则。关于OOD六大原则**1. 开闭原则，这个是比较具有理想主义色彩的，可以说面向对象设计的终极目标就是对你扩展开放对修改关闭的，其他的设计模式也是在追求这个目标而存在的。开闭原则的目的就是为了完成良好的设计，对修改的关闭保持了对已有设计的最佳保存方式，对扩展开放保持了系

工厂模式是设计模式中创建者模式非常重要的一种，一般有工厂模式，工厂方法模式，抽象工厂模式。这次主要谈一下工厂方法模式。 接口就是定义规则，抽象类就是定义部分的规则，具体类就是干活的，关于模式的理想原则就是面向对象几大原则 开闭，里氏代换，依赖倒置，迪米特（最小知识），接口隔离，合成复用。工厂方法模式 定义一个抽象的工厂客户端用以声明引用，具体工厂类实现抽象工厂完成产品实例化。定义产品接口，里

最近一直在关注集群与分布式的原理，难点在于服务的管理与协调， 现在应用最广的服务发现的方案就是Zookeeper，必须掌握。 集群与分布式的区别是集群提升的是可靠性，就是当部分的机器宕机不会导致服务不可用，每台机器提供完整的服务。分布式更强调的是将不同的业务拆分成不同的模块，不同的机器承载的业务也不同，因此分布式更多的提高性能。集群前面通常有一个负载均衡算法，将请求适当的分配到集群中去，对于用户来

最近升级一个版本的jetty7到jetty9，主要是因为jetty启动有个计数的变量是int型，如果运行久了会导致数据溢出，jetty9修复了这个问题，改成了long类型。修改了jetty依赖的jar版本。但是一直出现java.lang.NoSuchMethodError: javaxservlet.http.HttpServletRequest.isAsyncStarted()Z。后来查找相关资料

在面向对对象设计中，我们会通过构造各种各样的对象并组织对象之间的关系，但是在很多时候我们并不是很关心这个对象是怎么来的，或者是这个对象的创建是十分的复杂，而希望直接有个现成的方式直接去获取，客户可以直接拿来就可以使用也不用去维护这个对象的生命周期。 工厂模式也分三种比较常见的模式，简单工厂方法，工厂方法模式，抽象工厂模式简单工厂模式简单工厂模式的角色有三个：抽象产品角色具体产品，实现了抽象

面向对象设计六大原则： 开闭原则 依赖倒置 里氏替换原则 单一职责 接口隔离 迪米特法则 结构原则： 面向接口编程，原则上对象之间的关系尽量采用组合的方式而不是继承的方式，集成尽量不重写超类的方法。工厂方法有三种：简单工厂方法，静态工厂方法，抽象工厂方法。 工厂方法模式为创建对象的模式，为了解决的问题是对象创建的问题。1.简单工厂方法： 类图 代码实现如下：interfac

系统模块间的依赖往往开始于各种消息的传递，很多时候我们需要完成当某一件事情发生就要通知相关的关注方获得通知以便进行一系列活动。观察者模式就是这样一种设计模式，被关注者是产生变化的源头，因此在变化的源头去通知那些关注者相比较关注者主动去获取被关注者的变化会更加方便。 观察者模式的UML图如下： 有四个角色： 被观察者Obserable :定义被观察者应该有的功能，这里定义了添加观察者和移除观察者和

建造者模式属于创建型设计模式，我们经常需要创建一些对象，这个对象是由一些基本的部分组成的，但是考虑到各种情况，这些具体的部分会经常的发生改变，但是组织这些部件的顺序等等是不容易的变化的，这点类似乎模板方法模式遇到的使用场景，模板方法侧重点在于定义一个基本的算法骨架，建造者模式侧重点在于灵活的变更具体部件的实现。类图如下： 有三个角色需要解释： 1.Director类（导演类）：维护一个Bui

1. 如果说设计模式是对某种场景的最佳实践，那再在这些场景与设计上更进一步的提炼出的规范可以被总结为一系列面向对象设计的原则， 这些原则是更加抽象的一层，这些原则并不是某个厂商或者是语言的编写者确立的规范，而是在大量的实践中总结出来的经验，可以说是 优秀的面向对象设计大都符合这些规范，也可以说是在这些规范的约束下设计出良好的面向对象系统。开闭原则就是强调系统应该对扩展开放，

各个设计模式之间的关系图： 1、策略模式2、抽象工厂模式3、代理模式4、迭代器模式5、访问者模式6、工厂方法模式7、简单工厂模式 8、观察者模式9、建造者模式10、模板方法模式11、桥梁模式12、外观模式13、享元模式14、原型模式15、装饰模式16、组合模式

最近新项目一边做项目一边拜读了一下《大型网站技术技术架构》，一直对架构很感兴趣听说这本书算是架构的入门科普的书，在网上找电子档看了下，感觉非常不错所以就花了点钱去买了一本来认真的读了一下，书不厚但是内容比较丰富，由于是讲大型网站的演化和主要架构，因此作者不可能面面俱到，在豆瓣去看了下评分，的确两级分化比较严重。部分的读者出于对于作者的出身（作者李智慧阿里巴巴的技术总监）所以抱着挖掘宝藏的心态读拜读，