Java搜索工程技术栈

大型互联网架构设计，讲究一个组合拳玩法，、、、。如果能掌握这四个方面，应付大厂面试以及日常工作中的架构方案设计基本不是什么难题。今天，就带大家学习下都有哪些设计技巧？有句古话 "牵一发而动全身"。面对一个庞然大物，如果没有一个合理的分工分层。任何一个小小失误都会被无限放大，酿成巨大灾难。万物相通，回到我们的软件架构。早前的系统都是单体系统，比如电商业务，会员、商品、订单、物流、营销等模块都堆积在一个系统。每到节假日搞个大促活动，系统扩容时，一扩全扩，一挂全挂。只要一个接口出了问题，整个系统都不可用。“鸡蛋不

单服务器无论如何优化，无论采用多好的硬件，总会有一个性能天花板，当单服务器的性能无法满足业务需求时，就需要设计高性能集群来提升系统整体的处理性能。高性能集群的本质很简单，通过增加更多的服务器来提升系统整体的计算能力。由于计算本身存在一个特点：同样的输入数据和逻辑，无论在哪台服务器上执行，都应该得到相同的输出。因此高性能集群设计的复杂度主要体现在任务分配这部分，需要设计合理的任务分配策略，将计算任务分配到多台服务器上执行。高性能集群的复杂性主要体现在需要增加一个任务分配器，以及为任务选择一个合适的任务分配算法

架构师，这个职业在大部分人眼中，认为他们在IT领域无所不能，不但拥有高超的架构决策能力，还精通各项主流技术领域。在发生问题时，他们能够快速诊断故障并解决，在推进项目时，他们能够精准掌控各方面信息来源。企业对架构师的期望可能会更高，认为他们是能够推动整个科技文化转型的关键要素，是能够调动各个科技团队融合的核心角色。不知在你们心目中，架构师的形象是怎样的，是“超级英雄”还是“救世主”，但至少从我这二年对架构师的理解和认识而言，他们可能都不是。甚至他们仅仅是一个听上去比较高端的职业罢了，只不过是被大多数人给神化了

万物需要架构，比如国家的职能部门，有国务院/工商局/教育局等。企业的组织架构，有研发部/市场部/产品部等。 组织结构下的每一个部门，又会分很多角色，比如研发部，有技术部总监，技术Leader，技术架构师，研发工程师等，每个角色各自发挥角色价值。 互联网企业中架构师能力的好坏会决定软件系统的好坏，这个好坏体现在维护性，扩展性，成本，业务支撑效率等。 今天说说做好架构师工作需要具备的核心能力，该能力包括架构师的思维模式，架构师具备的架构原则，架构师深知的架构质量属性及程

如果看过我前面对服务限流的分析,理解服务降级就很容易了,对于一个景区,平时随便进出,但是一到春节或者十一国庆这种情况客流量激增,那么景区会限制同时进去的人数,这叫限流,那么什么是服务降级呢?简单来说就是,将一些不太重要的景区项目砍掉,平时就那么三五八个人,景区可以开放湖中游泳啦,摸鱼啦,捉虾啦,有情况工作人员可以下湖捞你,但是现在客流量大了,工作人员关注不过来,都在湖里晃荡万一沉了不太安全,大手一挥,这个项目砍了,将工作人员分配在其他地方。在互联网中也有类似的降级措施,像之前双11, 有段时间是只允许下单不

作者：faryrong，腾讯 CSIG 后台开发工程师领域驱动设计（DDD）由 Eric Evans 提出，并一经《领域驱动设计：软件核心复杂性应对之道》的发布，在软件行业中引起了不少的轰动。DDD 提供的一种新颖的，甚至有点“另类”的思维方式，它在告诉软件开发者“我们要用业务方案来解决业务问题，而不是技术方案解决业务问题”，有点魔法打败魔法的意思。DDD 虽然让人眼前一亮，但是所提倡的理念有点“违背直觉”（对开发人员而言），因此，在当时并没有流行开来。后来，微服务架构的兴起，大伙惊奇地发现 DDD 是作为

工作 20 多年了，这 20 来年看到了很多公司系统架构，也看到了很多问题，在跟这些公司进行交流和讨论的时候，包括进行实施和方案比较的时候，都有很多各种方案的比较和妥协，因为相关的经历越来越多，所以，逐渐形成了自己的逻辑和方法论。今天，想写下这篇文章，把我的这些个人的经验和想法总结下来，希望能够让更多的人可以参考和借鉴，并能够做出更好的架构来。另外，我的这些思维方式和原则都针对于现有市面上众多不合理的架构和方案，所以，也算是一种“纠正”……（注意，这篇文章所说的这些架构上的原则，一般适用于相对比较复杂的业务

说到常见负载均衡的分类，我们先来看看什么是 OSI 七层模型。我们常说的二层/三层/四层交换机，就是基于 OSI 七层模型所对应的层来命名的。我刚开始接触网络设备的时候，第一次听说二层交换机、三层交换机时，还以为交换机的硬件厚度有二层、有三层，后来才知道，其实是按照 OSI 七层模型来区别不同交换机的原理功能。OSI 七层模型主要作为一个通用模型来做理论分析，它是一个理论模型。而 TCP/IP 通信协议模型（四层）是互联网的实际通信协议，两者一般做映射对比及分析。OSI 七层模型及对应的传输协议而常见的负载

正如题图所示的这样，由一个独立的统一入口来收敛流量，再做二次分发的过程就是「负载均衡」，它的本质和「分布式系统」一样，是「分治」。如果大家习惯了开车的时候用一些导航软件，我们会发现，导航软件的推荐路线方案会有一个数量的上限，比如3条、5条。因此，其实本质上它也起到了一个类似「负载均衡」的作用，因为如果只能取Top3的通畅路线，自然拥堵严重的路线就无法推荐给你了，使得车流的压力被分摊到了相对空闲的路线上。在软件系统中也是一样的道理，为了避免流量分摊不均，造成局部节点负载过大（如CPU吃紧等），所以引入一个独立

1 前言如今，在各种互联网应用中，随着站点对硬件性能、响应速度、服务稳定性、数据可靠性等要求也越来越高，单台服务器也将难以无法承担所有的访问需求。当然了，除了使用性价比高的设备和专用负载分流设备外，还有一些其他选择来帮你解决此问题，就是搭建集群服务器通过整合多台普通的服务器设备并以同一个地址对外提供相同的服务，今天就带领大家学习企业中常用的一种集群技术 —— LVS。1 什么是 LVS？LVS：是Linux Virtual Server的简写，也就是Linux 虚拟服务器，是一个虚拟的...

1 前言在嵌入式系统中，很少需要使用到 RPC (Remote Procedure Call)远程方法调用，因为在大部分情况下，实现一个产品功能的所有进程、线程都是运行在同一个硬件设备中的。但是在一些特殊的场景中，RPC 调用还是很有市场的，比如：在计算密集型产品中，需要调用算力更强的中央服务器提供的算法函数；因此，利用 RPC 来利用远程提供的服务，相对于其他的机制来说，有更多的优势。这篇文章我们就来聊一聊 RPC 的相关内容，来看一下如何利用 Google 的开源序列化工具pr.

想知道未来是不是 gRPC 的天下？本文会具体介绍两种 API 架构风格：REST 和 gRPC，并讨论它们之间的区别。不过，首先，我们会解释什么是 API，以及为什么它对微服务基础设施而言至关重要。之后，我们会介绍 gRPC 的基础——RPC，并探讨 gRPC 和 REST API 之间的重要差异。根据它们的对比结果，我们最后会分析什么时候应该使用哪种架构类型。1 API 是什么API，即应用程序编程接口。这些接口充当软件中介，为应用程序之间的交互和对话建立特定的定义和规则。API 负责将响应从用

一、微服务架构介绍微服务架构（Microservice Architecture）是一种架构概念，旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。你可以将其看作是在架构层次而非获取服务的类上应用很多SOLID原则。微服务架构是个很有趣的概念，它的主要作用是将功能分解到离散的各个服务当中，从而降低系统的耦合性，并提供更加灵活的服务支持。概念：把一个大型的单个应用程序和服务拆分为数个甚至数十个的支持微服务，它可扩展单个组件而不是整个的应用程序堆栈，从而满足服务等级协议。定义：围绕..

一、前言最近在 github 上看了 soul 网关的设计，突然就来了兴趣准备自己从零开始写一个高性能的网关。经过两周时间的开发，我的网关 ship-gate 核心功能基本都已完成，最大的缺陷就是前端功底太差没有管理后台 😤。二、设计2.1 技术选型网关是所有请求的入口，所以要求有很高的吞吐量，为了实现这点可以使用请求异步化来解决。目前一般有以下两种方案： Tomcat/Jetty+NIO+Servlet3 Servlet3 已经支持异步，这种方案使用比较多，京东，有赞和 Zuul

前言最近几年，随着微服务的流行，服务和服务之间的依赖越来越强，调用关系越来越复杂，服务和服务之间的稳定性越来越重要。在遇到突发的请求量激增，恶意的用户访问，亦或请求频率过高给下游服务带来较大压力时，我们常常需要通过缓存、限流、熔断降级、负载均衡等多种方式保证服务的稳定性。其中限流是不可或缺的一环，这篇文章介绍限流相关知识。1. 限流限流顾名思义，就是对请求或并发数进行限制；通过对一个时间窗口内的请求量进行限制来保障系统的正常运行。如果我们的服务资源有限、处理能力有限，就需要对调用我们服务的上游请

引出四个维度工作快十五年了，从十年前开始经常会有新项目，需要从头开始做方案和设计。做技术选型很少成为我的难题。不是因为这方面我多有方法，而通常是很少有选择。在做技术选型的场景下基本有以下四个维度：维度一从系统构成上有两种：第一种，有之前的老系统，需要重构第二种，从零开始建的服务维度二从稳定性要求上有三种：第一种，现在没有什么业务量，将来估计也不会有什么增长，甚至很可能不成第二种，现在没有什么业务量，将来对稳定性要求很高第三种，现在对有稳定性要求很高维度三从环境

本篇内容主要讲解的是redis分布式锁，这个在各大厂面试几乎都是必备的，下面结合模拟抢单的场景来使用她；本篇不涉及到的redis环境搭建，快速搭建个人测试环境，这里建议使用docker；本篇内容节点如下：Jedis的nx生成锁 如何删除锁 模拟抢单动作(10w个人开抢) jedis的nx生成锁 对于java中想操作redis，好的方式是使用jedis，首先pom中引入依赖：<dependency> <groupId>redis.clie

讲师介绍陈永庭，饿了么框架工具部高级架构师，主要负责MySQL异地双向数据复制，支撑饿了么异地多活项目。曾就职于WebEx、Cisco、腾讯等公司。今天我主要分享饿了么多活的底层数据实施，会和大家介绍在整个多活的设计和实施过程中我们是怎么处理异地数据同步的，而这个数据同步组件在我们公司内部称之为DRC。异地多活背景在讲DRC或者讲数据复制之前，先跟大家回顾一下异地多活的背景。去年我们在做多活调研的时候，整个公司所有的业务服务都是部署在北京机房，服务器大概有四千多台，灾备的机器是在云端

在饿了么，一个应用如果要访问MySQL、Redis、MQ等基础组件，都是通过一个本地的透明代理来完成的。该代理将基础组件服务化，屏蔽了分布式环境中的集群发现、健康检查和负载均衡等细节，让应用使用起来如单机时一样简单，能够直接使用各语言现有的 SDK，无需任何改动。背景在内部最初迁移至SOA架构的时候，我们在应用的每台机器上部署了HAProxy，用于代理到基础组件的流量。起初由于内部服务的数量和变更都比较少，这个方案工作的还不错；但随着服务的增多和实例频繁的变更发布，这种方案的弊端逐渐显现出来，...

作者介绍张sir，京东到家研发工程师，主要负责订单中心、商家中心、计费等系统。京东到家订单中心系统业务中，无论是外部商家的订单生产，或是内部上下游系统的依赖，订单查询的调用量都非常大，造成了订单数据读多写少的情况。我们把订单数据存储在MySQL中，但显然只通过DB来支撑大量的查询是不可取的。同时对于一些复杂的查询，MySQL支持得不够友好，所以订单中心系统使用了Elasticsearch来承载订单查询的主要压力。Elasticsearch作为一款功能强大的分布式搜索引擎，支持近实

MySQL + HBase是我们日常应用中常用的两个数据库，分别解决应用的在线事务问题和大数据场景的海量存储问题。# 从架构对比看差异相比MySQL，HBase的架构特点:1.完全分布式（数据分片、故障自恢复)2.底层使用HDFS(存储计算分离)。由架构看到的能力差异:1. MySQL:运维简单(组件少)、延时低(访问路径短)2.HBase:扩展性好、内置容错恢复与数据冗余#从引擎结构看差异相比MySQL，HBase的内..

提起分库分表，对于大部分服务器开发来说，其实并不是一个新鲜的名词。随着业务的发展，我们表中的数据量会变的越来越大，字段也可能随着业务复杂度的升高而逐渐增多，我们为了解决单表的查询性能问题，一般会进行分表操作。同时我们业务的用户活跃度也会越来越高，并发量级不断加大，那么可能会达到单个数据库的处理能力上限。此时我们为了解决数据库的处理性能瓶颈，一般会进行分库操作。不管是分库操作还是分表操作，我们一般都有两种方式应对，一种是垂直拆分，一种是水平拆分。关于两种拆分方式的区别和特点，互联网上参考资料众多，很多

设计模式中,最广为人知的就是单例模式了吧,相信知道单例模式的人,也知道实现单例模式有几种方法,目前用的最多的就是 双重锁,静态内部类,枚举。网上大都推荐枚举方式实现单例。因为使用枚举实现的单例模式,更简洁更安全。但是使用枚举实现的单例模式真的就万无一失了吗？下面我使用枚举实现的单例模式：@Slf4jpublic enum LoggerQueue implements Serializable { INSTANCE; /** * 队列大小 * 这个队

非线程安全方式单例缺点：非线程安全，不可取。package com.wenxiaowu.dp.singleton;import java.util.Set;import java.util.concurrent.CopyOnWriteArraySet;import java.util.concurrent.CountDownLatch;/** * 非线程安全方式单例 */class NotSafeSingleton { private NotSafeSingleton()

1.策略模式(Strategy Pattern)策略模式体现了两个非常基本的面向对象设计的原则（1）封装变化的概念解说：TreeSet或者说TreeMap仅仅只知道接受一个Comparator这样一个类型，但是具体的是哪一个实现类，在我们传入之前是不知道的，它只知道Comparator这样一个接口。因此我们可以自己去实现Comparator这样一个接口，然后封装成我们自己的比较规则，即实现我们自己的变化。（2）编程中使用接口，而不是对接口的实现面向接口的编程2.策略模式的定义定义了一组算

责任链模式怎么使用呢？ 一个接口或者抽象类 每个对象差异化处理 对象链（数组）初始化（连起来） 2.3.1 一个接口或者抽象类这个接口或者抽象类，需要： 有一个指向责任下一个对象的属性 一个设置下一个对象的set方法 给子类对象差异化实现的方法（如以下代码的doFilter方法） /***关注公众号：捡田螺的小男孩*/publicabstractclassAbstractHandler{//责任链中的下一个对...

在模板模式（Template Pattern）中，一个抽象类公开定义了执行它的方法的方式/模板。它的子类可以按需要重写方法实现，但调用将以抽象类中定义的方式进行。这种类型的设计模式属于行为型模式。介绍意图：定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。主要解决：一些方法通用，却在每一个子类都重新写了这一方法。何时使用：有一些通用的方法。如何解决：将这些通用算法抽象出来。关键代码：在抽象类实现，其他步骤在子

当对象间存在一对多关系时，则使用观察者模式（Observer Pattern）。比如，当一个对象被修改时，则会自动通知依赖它的对象。观察者模式属于行为型模式。介绍意图：定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。主要解决：一个对象状态改变给其他对象通知的问题，而且要考虑到易用和低耦合，保证高度的协作。何时使用：一个对象（目标对象）的状态发生改变，所有的依赖对象（观察者对象）都将得到通知，进行广播通知。如何解决：使用面向对象技术，

工厂模式（Factory Pattern）是 Java 中最常用的设计模式之一。这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。在工厂模式中，我们在创建对象时不会对客户端暴露创建逻辑，并且是通过使用一个共同的接口来指向新创建的对象。介绍意图：定义一个创建对象的接口，让其子类自己决定实例化哪一个工厂类，工厂模式使其创建过程延迟到子类进行。主要解决：主要解决接口选择的问题。何时使用：我们明确地计划不同条件下创建不同实例时。如何解决：让其子类实现工厂接口，返回的也是一个抽

本文介绍策略模式的具体应用以及Map+函数式接口如何 “更完美” 的解决 if-else的问题。文章目录 需求 策略模式 Map+函数式接口 最后捋一捋本文讲了什么 需求最近写了一个服务：根据优惠券的类型resourceType和编码resourceId来 查询 发放方式grantType和领取规则实现方式： 根据优惠券类型resourceType -> 确定查询哪个数据表 根据编码resourceId -> 到对应的数据表里边

编程是一个先思考再编码的过程，思考是优于编码技能的，在思考过程中我们会考虑代码的可重用性、可靠性、更容易被他人理解，这时就会使用到设计模式让代码编写工程化，这篇文章整理了设计模式的六大原则。1. 单一职责原则单一职责原则（Single Responsibility Principle）There should never be more than one reason for a class to change.（有且仅有一个原因可以引起类的变更）不管让我干啥，我都只干一件事，你让我下楼取快

前言关于设计模式和代码规范问题还是有一些内容还是值得落笔和大家分享的。正文设计模式究竟是什么？主流的说法，大致如此：设计模式是解决可在许多不同情况下使用的问题的描述或模板，一般在OOP中最作为最佳实践的解决方案。最佳实践一词笔者再几处介绍设计模式的地方，都有看到。但是设计模式真的就是OOP中，业务开发的最佳实践吗？首先声明笔者的观点，我是如何理解设计模式的：设计模式是一种代码规范，不同于空格，缩进这类容易被插件检测的入门规范，是一种中级代码规范，不宜被入门者理解，不易被插件所

关于怎么实现承载更多用户量的系统，一直是我重点关注的一个技术方向。改造架构提高承载力，通常来讲分为两个大方向，互相配合实现。硬件架构改进，主要是使用阿里云这种多组件的云环境：通过负载均衡SLB，模版克隆的云服务器ECS，云数据库RDS，共享对象存储OSS等不同职责的云产品组合实现。软件架构优化，主要是软件代码开发的规范：业务解耦合，架构微服务，单机无状态化，文件存储共享等在分布式系统的学习途中也不断见识新的知识点，今天要说的就是软件开发时候对于接口服务的“幂等性”实现！福利：这次面试稳了！看

近2年Docker非常的火热，各位开发者恨不得把所有的应用、软件都部署在Docker容器中，但是您确定也要把数据库也部署的容器中吗？这个问题不是子虚乌有，因为在网上能够找到很多各种操作手册和视频教程，小编整理了一些数据库不适合容器化的原因供大家参考，同时也希望大家在使用时能够谨慎一点。目前为止将数据库容器化是非常不合理的，但是容器化的优点相信各位开发者都尝到了甜头，希望随着技术的发展能够更加完美的解决方案出现。Docker不适合部署数据库的7大原因1、数据安全问题不要将数据储存在容器中，

技术传播的价值，不仅仅体现在通过商业化产品和开源项目来缩短我们构建应用的路径，加速业务的上线速率，也体现在优秀工程师在工作效率提升、产品性能优化和用户体验改善等经验方面的分享，以提高我们的专业能力。本文作者阿里巴巴技术专家三画，分享了自己和团队在画好架构图方面的理念和经验，首发于阿里内部技术分享平台，阿里巴巴中间件授权转载，梓敬、鹏升和余乐对此文亦有贡献。当我们想用一张或几张图来描述我们的系统时，是不是经常遇到以下情况： 对着画布无从下手、删了又来？ 用一张图描述我的系统，并且让.