消息疯狂堆积！RocketMQ 出 Bug 了?

消息疯狂堆积！RocketMQ 出 Bug 了?

Comments 0 Comment  162 Views

閱讀本文約花費: 21 (分鐘)前言 用过 MQ 的同学，可能会遇到过消息堆积的问题。而肥壕最近也踩上了这个坑，但是发现结果竟然是这么一个意料之外的原因而导致的。 正文 那一晚月黑风高，肥壕正准备踏上回家的路，突然收到告警短信轰炸！“MQ 消息堆积告警 [TOPIC: XXX] ” 肥壕心里“万只草泥马崩腾~” 第一反应是：“怎么肥事？刚下班就来搞事情？？？” 于是乎赶回公司赶紧打开电脑，登上 RocketMQ 后台查看（公司自己搭建的开源版RocketMQ） 握草 (ｷ｀ﾟДﾟ´)!!! 竟然堆积了3亿多条消息了？？？ 要知道出现消息堆积无在乎这个问题： 生产者的生产速度 >> 消费者的处理速度  1. 生产者的生产速度骤增，比如生产者的流量突然骤增 2. 消费速度变慢，比如消费者实例 IO 阻塞严重或者宕机 擦了一下头上的冷汗😓…赶紧登上消费者服务器瞧瞧。 应用运行正常！服务器磁盘IO 正常！网络正常！ 再去上去生产者的服务器，咦…流量也很正常！ 什么？？？佛了😨 …生产者和消费者的应用都很正常，但是为什么消息会堆积怎么多呢？看着这堆积的数量越堆越多（要是这是我头发的数量那该多好啊），越发着急。 虽然说 RocketMQ 版能支持 10 亿级别的消息堆积，不会因为消息堆积导致性能明显下降，&#x1…

Read More Read More

数据库的乐观锁和悲观锁并非真实的锁

数据库的乐观锁和悲观锁并非真实的锁

Comments 0 Comment  157 Views

閱讀本文約花費: 10 (分鐘)开局 我们平时编写程序的时候，有很多情况下需要考虑线程安全问题，一个全局的变量如果有可能会被多个同时执行的线程去修改，那么对于这个变量的修改就需要有一种机制去保证值的正确性和一致性，这种机制普遍的做法就是加锁。其实也很好理解，和现实中一样，多个人同时修改一个东西，必须有一种机制来把多个人进行排队。计算机的世界中也是如此，多个线程乃至多个进程同时修改一个变量，必须要对这些线程或者进程进行排队。数据库的世界亦是如此，多个请求同时修改同一条数据记录，数据库必须需要一种机制去把多个请求来顺序化，或者理解为同一条数据记录同一时间只能被一个请求修改。 锁是数据库中最为重要的机制之一，无论平时写的select语句，还是update语句其实在数据库层面都和锁息息相关。如果没有锁机制，操作数据的时候可能会发生以下情况： 更新丢失：多个用户同时对一个数据资源进行更新，必定会产生被覆盖的数据，造成数据读写异常。 不可重复读：如果一个用户在一个事务中多次读取一条数据，而另外一个用户则同时更新啦这条数据，造成第一个用户多次读取数据不一致。 脏读：第一个事务读取第二个事务正在更新的数据表，如果第二个事务还没有更新完成，那么第一个事务读取的数据将是一半为更新过的，一半还没更新过的数据，这样的数据毫无意义。 幻读：第一个事务读取一个结果集后，第二个事务，对这个结果集经行增删操作，然…

Read More Read More

分布式定时任务调度框架实践

分布式定时任务调度框架实践

Comments 0 Comment  213 Views

閱讀本文約花費: 14 (分鐘)分布式任务调度框架几乎是每个大型应用必备的工具，本文介绍了任务调度框架使用的需求背景和痛点，对业界普遍使用的开源分布式任务调度框架的使用进行了探究实践，并分析了这几种框架的优劣势和对自身业务的思考。 一、业务背景 1.1 为什么需要使用定时任务调度 （1）时间驱动处理场景：整点发送优惠券，每天更新收益，每天刷新标签数据和人群数据。 （2）批量处理数据：按月批量统计报表数据，批量更新短信状态，实时性要求不高。 （3）异步执行解耦：活动状态刷新，异步执行离线查询，与内部逻辑解耦。 1.2 使用需求和痛点 （1）任务执行监控告警能力。 （2）任务可灵活动态配置，无需重启。 （3）业务透明，低耦合，配置精简，开发方便。 （4）易测试。 （5）高可用，无单点故障。 （6）任务不可重复执行，防止逻辑异常。 （7）大任务的分发并行处理能力。 二、开源框架实践与探索  2.1 Java 原生 Timer 和ScheduledExecutorService 2.1.1 Timer使用 Timer缺陷： Timer底层是使用单线程来处理多个Timer任务，这意味着所有任务实际上都是串行执行，前一个任务的延迟会影响到之后的任务的执行。 由于单线程的缘故，一旦某个定时任务在运行时，产生未处理的异常，那么不仅当前这个线程会停止，所有的定时任务都会停止。 Timer任…

Read More Read More

上 Kubernetes 到底有什么业务价值？

上 Kubernetes 到底有什么业务价值？

Comments 0 Comment  102 Views

閱讀本文約花費: 13 (分鐘)开篇，我们先思考这样一个问题：“为什么要基于 Kubernetes 去构建一个应用管理平台？” 上图是一个本质的问题，我们在落地 K8s 经常遇到的一个问题。尤其是我们的业务方会问到这么一个问题，我们上 Kubernetes 有什么业务价值？这时候作为我们 K8s 工程师往往是很难回答的。原因在哪里呢？实际上这跟 K8s 的定位是相关的。K8s 这个项目呢，如果去做一个分析的话，我们会发现 K8s 不是一个 PaaS 或者应用管理的平台。实际上它是一个标准化的能力接入层。什么是能力接入层呢？大家可以看一下下图。 实际上通过 Kubernetes 对用户暴露出来的是一组声明式 API，这些声明式 API 无论是 Pod 还是 Service 都是对底层基础设施的一个抽象。比如 Pod 是对一组容器的抽象，而 Deployment 是对一组 pod 的抽象。而 Service 作为 Pod 的访问入口，实际上是对集群基础设施：网络、网关、iptables 的一个抽象。Node 是对宿主机的抽象。Kubernetes 还提供了我们叫做 CRD（也就是 Custom Resource）的自定义对象。让你自己能够自定义底层基础设施的一个抽象。 而这些抽象本身或者是 API 本身，是通过另外一个模式叫做控制器 (Controller) 去实现的。通过控制器去驱动…

Read More Read More

学了那么多技术，为何依然成不了架构师

学了那么多技术，为何依然成不了架构师

Comments 0 Comment  189 Views

閱讀本文約花費: 13 (分鐘)在我们的周围存在着很多的全栈工程师，极客达人，他们热爱技术，善于使用各种工具，甚至可以熟练使用多种开发语言，解决各种技术上的问题，但是却无法成为掌控全局的架构师，无法做出最优的架构决策，这是为什么呢？ 架构中的哲学 在《道德经》中提到四个字，叫“道、法、术、器”。“道”是天道，“法”是人定的，就是说你该怎么跟着“天道”去做。“法”也有善恶之分。顺应天道的“法”就是善法，相反，违背天道的“法”就是恶法。“术”是指技术层面上的操作方法。“器”是指有型的物质或是有形的工具。 无独有偶，在学习阳明心学的时候，其核心教义也和道家思想一脉相承。 无善无恶是自然之道，有善有恶是人性之法，知善知恶需判别之术，为善去恶用合法之器。他们不是含义上的等价，却是哲学思想层次的完美统一。从道出发，以法为界，以道御术，善于用器。这是一个循序渐进的过程，是解决问题的步骤和方法论。 对于大部分程序员来说，不论是我们参与的工作，还是接受的培训，基本都属于“器”、“术”的范畴。而架构师具备能力：理解业务，全局把控（道），选择合适技术（法），解决关键问题（术），指导研发落地实施（器）。可见成为一名合格的架构师，不仅仅只是具备技术能力就可以完全胜任的，还需要领悟架构之道，架构之法并合理的应用。 何为架构的道、法、术、器呢？ 道：架构设计的方向，大道至简。 法：架构设计的原则，有据可依。 术…

Read More Read More

云计算术语（中英文对照）

云计算术语（中英文对照）

Comments 0 Comment  228 Views

閱讀本文約花費: 7 (分鐘)以下搜集了一些在云计算中会比较常遇到的一些术语，提供中英对照信息： 1. 自由计算      free computing  2. 弹性可伸缩    elastic and scalable  3. 主机          host / instance  4. 硬盘          hard disk/ volume  5. 密钥          key  6. 公开密钥      public key  7. 映像          image / mapping  8. 负载均衡      load balancing  9. 对象存储      object storage  10. 弹性计算      elastic computing  11. 按秒计费   &nb…

Read More Read More

如何构建以应用为中心的“Kubernetes”?

如何构建以应用为中心的“Kubernetes”?

Comments 0 Comment  152 Views

閱讀本文約花費: 23 (分鐘)在上篇文章《上 Kubernetes 到底有什么业务价值？》，主要和大家介绍了上 Kubernetes 有什么业务价值，以及什么是“以应用为中心”的 Kubernetes。本文将跟大家具体分享如何构建“以应用为中心”的 Kubernetes。 如何构建“以应用为中心”的 Kubernetes？ 构建这么一个以用户为中心的 Kubernetes，需要做几个层级的事情。 1. 应用层驱动 首先来看最核心的部分，上图中蓝色部分，也就是 Kubernetes。可以在 Kubernetes 之上定义一组 CRD 和 Controller。可以在 CRD 来做用户这一侧的 API，比如说 pipeline 就是一个 API，应用也是一个 API。像运维侧的扩容策略这些都是可以通过 CRD 的方式安装起来。 2. 应用层抽象 所以我们的需要解决第一个问题是应用抽象。如果在 Kubernetes 去做应用层抽象，就等同于定义 CRD 和 Controller，所以 Controller 可以叫做应用层的抽象。本身可以是社区里的，比如 Tekton，istio 这些，可以作为你的应用驱动层。这是第一个问题，解决的是抽象的问题。不是特别难。 3. 插件能力管理 很多功能不是 K8s 提供的，内置的 Controller 还是有限的，大部分能力来自于社区或者是自己开发的 …

Read More Read More

蚂蚁金服大规模微服务架构下的Service Mesh探索之路

蚂蚁金服大规模微服务架构下的Service Mesh探索之路

Comments 0 Comment  46 Views

閱讀本文約花費: 44 (分鐘)前言 今天给大家带来的内容叫做Service Mesh探索之路，但是在前面加了一个定语：大规模微服务架构下。之所以加上这个词，是因为我们这个体系是在蚂蚁金服这样一个大的架构下进行的，蚂蚁金服的体量大家可以想象，所以这个探索会带有一个非常隆重的色彩：对性能/规模/高可用等方面的思考。 在深圳的GIAC大会，我们同事披露了这个正在开发中的 Service Mesh产品，我们现在暂时命名为 SOFA Mesh。我们目前的产品都在 SOFA品牌下，比如 SOFA RPC，SOFA Boot等。今天我们详细介绍 SOFA Mesh这个单独产品，上次大会只是简单披露，也就是给大家介绍说我们有这样一个产品，而我今天的内容是把这个产品详细展开。 一、技术选型 先上来一堆要求，刚才我们提到过的，因为是大规模，而蚂蚁金服的体量，大家可以想象到的。实际上在性能，稳定性上，我们的衡量标准，我们考虑的基石，都是以蚂蚁金服这样的一个规模来考虑的。 在这样一个规模下，我们会涉及到一些跟其他公司不太一样的地方，比如说：我们在性能的考量上会比较重一些。因为如果性能不高的话，可能没法支撑我们这样一个规模。在考虑性能的时候，就有另外一层考量：架构和性能之间的这个权衡和取舍是要非常谨慎的。性能要求不太高的情况下，架构可能的选择，和需要比较高性能的情况下，可能会有完全不一样的取舍。稳定性就不…

Read More Read More

【权限系统设计】ACL, DAC, MAC, RBAC, ABAC 模型的不同应用场景

【权限系统设计】ACL, DAC, MAC, RBAC, ABAC 模型的不同应用场景

Comments 0 Comment  159 Views

閱讀本文約花費: 8 (分鐘)ACL 访问控制列表 规定资源可以被哪些主体进行哪些操作 场景：部门隔离 适用资源：客户页面、人事页面 在ACL权限模型下，权限管理是围绕资源来设定的。我们可以对不同部门的页面设定可以访问的用户。配置形式如下： ACL配置表 资源: 客户页面 主体: 销售部（组） 操作：增删改查 主体: 王总（用户） 操作: 增删改查 资源: 人事页面 主体: 王总（组） 操作: 增删改查 注：主体可以是用户，也可以是组。 在维护性上，一般在粗粒度和相对静态的情况下，比较容易维护。 在细粒度情况下，比如将不同的客户视为不同的资源，1000个客户就需要配置1000张ACL表。如果1000个客户的权限配置是有规律的，那么就要对每种资源做相同的操作；如果权限配置是无规律的，那么ACL不妨也是一种恰当的解决方案。 在动态情况下，权限经常变动，每添加一名员工，都需要配置所有他需要访问的资源，这在频繁变动的大型系统里，也是很难维护的。 在一些情况下，ACL也可应用于细粒度场景，接下来将介绍两种ACL的拓展。 DAC 自主访问控制 规定资源可以被哪些主体进行哪些操作 同时，主体可以将资源、操作的权限，授予其他主体 场景：文件系统 适用资源：人事培训文档 DAC是ACL的一种实现，强调灵活性。纯粹的ACL，权限由中心管理员统一分配，缺乏灵活性。为了加强灵活性，在ACL的基础…

Read More Read More

Dockerfile文件详解

Dockerfile文件详解

Comments 0 Comment  100 Views

閱讀本文約花費: 6 (分鐘)什么是dockerfile? Dockerfile是一个包含用于组合映像的命令的文本文档。可以使用在命令行中调用任何命令。 Docker通过读取Dockerfile中的指令自动生成映像。 docker build命令用于从Dockerfile构建映像。如果默认的文件名不叫Dockerfile，则可以在命docker build令中使用-f标志指向文件系统中任何位置的Dockerfile。注意最后面的“.”，代表的当前目录。 #例：docker build -t centos . #或者：docker build -f /path/dockerfile Dockerfile的基本结构 Dockerfile 一般分为四部分：基础镜像信息、维护者信息、镜像操作指令和容器启动时执行指令，’#’ 为 Dockerfile 中的注释。 Dockerfile文件说明 Docker以从上到下的顺序运行Dockerfile的指令。为了指定基本映像，第一条指令必须是FROM。一个声明以＃字符开头则被视为注释。可以在Docker文件中使用RUN，CMD，FROM，EXPOSE，ENV等指令。 在这里列出了一些常用的指令。 FROM：指定基础镜像，必须为第一个命令 BashCopy MAINTAINER: 维护者信息 BashCopy RUN：构建镜像时执行的命令 …

Read More Read More

Kubernetes 网络通讯模型解析

Kubernetes 网络通讯模型解析

Comments 0 Comment  143 Views

閱讀本文約花費: 7 (分鐘)Kubernetes 基础架构 架构图 从架构图看到，一次外部访问请求，并不会直接请求到kubernetes中具体的某个集群或者某一个资源模块，是需要经过各模块资源间的调度来完成的。网络 继续剖析Kubernetes的网络，如上图我们可以发现Kubernetes存在3种网络：节点网络，Pod网络，Service网络，最后再加上Internet与Service之间的网络总共4种。 于是我们可以总结Kubernetes需要解决4种通信模式：     1.容器和容器之间的通信     2.Pod和Pod之间的通信     3.Pod和Service之间的通信     4.Internet和Service之间的通信 容器和容器之间的网络 每一个Pod管理着一个或多个container，而对于同一个Pod之间的容器之间共享一个网络命名空间，它们之间可以直接通过localhost进行访问通信，这里以docker作为容器为例，容器间正好采用了container模式，额外创建启动一个容器，而这个容器不会有自己的网卡以及配置IP地址，而是和一个指定的容器共享IP和端口； 在Kubernetes里面每一个Pod都有…

Read More Read More

炸裂！40+ 图万字长文拿下 HTTP

炸裂！40+ 图万字长文拿下 HTTP

Comments 0 Comment  175 Views

閱讀本文約花費: 38 (分鐘)>本文将从以下几个方面进行分享。其中包括HTTP发展史，HTTP缓存代理机制，常用的web攻击，HTTP和HTTPS的流量识别，网络协议学习的工具推荐以及高频HTTP与HTTPS的高频面试题题解等，开工。 @ 1989年，蒂姆·伯纳斯 – 李（Tim Berners-Lee）在论文中提出可以在互联网上构建超链接文档，并提出了三点. URI：统一资源标识符。互联网的唯一ID HTML：超文本文档 HTTP:传输超文本的文本传输协议 1 HTTP应用在哪儿 学习一门知识，采用五分钟时间看看这个知识是干啥的可能会更加有目的性。HTTP可谓无处不在，这里例举出几个。 2 HTTP是什么 HTTP(hypertext transport protocol)翻译过来为”超文本传输协议”，文本可以理解为简单的字符文字组合，也可以理解为更为复杂的音频或者图像等。那么将这个词语拆分为三个部分。 “超文本”和”文本”相比多了一个字”超”，这样看来比文本丰富，因为它可以将多种文本/图像等进行混合，更重要的是可以从一个文本跳转到另一个文本(文本连接)。 “传输”，传输的过程中需要沟通，沟通即可能一对一沟通也可能一对多沟通(进行内容协商)，…

Read More Read More

云原生：「落地」最重要

云原生：「落地」最重要

Comments 0 Comment  122 Views

閱讀本文約花費: 17 (分鐘)1 云原生这个话题虽然我们谈了很多年了，但到底怎么去理解它，还是需要一段过程。提到云原生，很多人会联想到另一个词：「互联网原住民」，这个词代表了一群出生在互联网时代的人，他们看待世界和思考问题的方式从一开始就和互联网时代以前的人不同。 云原生也是如此。未来我们构建任何系统，不再是原来的那套思考方式，不是把云当成一个工具来使用，而是系统本身就生长于云，并在云上爆发，因此需要我们从根本上转换思考方式，重新定义业务系统。云原生和云计算也不一样，云计算的主角是计算、机器、资源，而云原生的主角是云上延伸出来的应用。 阿里云智能事业群总裁行癫曾经写过一个故事： 在 2004 年那个缺电的夏天，淘宝网全都挤在华星二楼：正是在那里，开始了我的淘宝生涯。我的位置在一个角落里，边上是一堆开着的服务器，吹出的风比七月烈阳下的风更热：因为限电，空调基本上只能看。刚到一个新环境，不知道该做什么，眼睁睁地看着一大群人忙忙碌碌。那时淘宝的节奏是非常快的，我记得小宝有一次说，当时网站如果要改点什么，只要跑到多隆那儿说一下，等他接杯水回到座位打开页面时，需求就已经上线了。 那是 2004 年，基于当时的技术架构，任何需求只要改一下代码，就能够立刻交付。而在现在这样复杂的技术架构下，很难通过简单修改代码实现需求迭代。 但是随着云原生时代的到来，我们又看到了新的机会。为了再现“当年的传说…

Read More Read More

语雀的技术架构演进之路

语雀的技术架构演进之路

Comments 0 Comment  158 Views

閱讀本文約花費: 21 (分鐘)每个技术人心中或多或少都有一个「产品梦」，好的技术需要搭配好的产品，才能让用户爱不释手，尤其是做一款知识服务型产品。 作者何翊宇（花名：不四）是蚂蚁金服体验技术部高级前端技术专家，语雀产品技术负责人。本文从技术架构的视角，回顾了语雀的原型、内部服务和对外商业化的全过程，并对函数计算在语雀架构演进过程中所扮演的角色做了详细的介绍。 语雀是一个专业的云端知识库，用于团队的文档协作。现在已是阿里员工进行文档编写和知识沉淀的标配，并于 2018 年开始对外提供服务。 1 原型阶段 回到故事的开始。 2016 年，语雀孵化自蚂蚁科技，当时，蚂蚁金融云需要一个工具来承载它的文档，负责的技术同学利用业余时间，搭建了这个文档工具。项目的初期，没有任何人员和资源支持，同时也是为了快速验证原型，技术选型上选择了最低成本的方案。 底层服务完全基于体验技术部内部提供的 BaaS 服务和容器托管平台： Object 服务：一个类 MongoDB 的数据存储服务； File 服务：阿里云 OSS 的基础上封装的一个文件存储服务； DockerLab：一个容器托管平台； 这些服务和平台都是基于 Node.js 实现的，专门给内部创新型应用使用，也正是由于有这些降低创新成本的内部服务，才给工程师们提供了更好的创新环境。 语雀的应用层服务端，自然而然的选用了蚂蚁体验技术部开源的 No…

Read More Read More

数据中心网络架构浅谈（一）

数据中心网络架构浅谈（一）

Comments 0 Comment  122 Views

閱讀本文約花費: 14 (分鐘)不论我们在讨论SDN，NFV或者其他的虚拟网络技术，有一点需要明确，网络数据包最终都是跑在物理网络上。物理网络的特性，例如带宽，MTU，延时等，最终直接或者间接决定了虚拟虚拟网络的特性。可以说物理网络决定了虚拟网络的“天花板”。在Mirantis对OpenStack Neutron的性能测试报告中可以看出，网络设备的升级和调整，例如采用高速网卡，配置MTU9000，可以明显提高虚拟网络的传输效率。在对网络性能进行优化时，有些物理网络特性可以通过升级设备或线路来提升，但是有些与网络架构有关。升级或者改动网络架构带来的风险和成本是巨大的，因此在架设数据中心初始，网络架构的选择和设计尤其需要谨慎。另一方面，在设计虚拟网络时，不可避免的需要考虑实际的物理网络架构，理解物理网络架构对于最终理解虚拟网络是不可缺少的。 接下来我将分几次说一说自己对数据中心网络架构的认识，想到哪说到哪，不对的地方请大家指正。 传统数据中心网络架构 在传统的大型数据中心，网络通常是三层结构。Cisco称之为：分级的互连网络模型（hierarchical inter-networking model）。这个模型包含了以下三层： Access Layer（接入层）：有时也称为Edge Layer。接入交换机通常位于机架顶部，所以它们也被称为ToR（Top of Rack）交换机，它们物理…

Read More Read More

Kubernetes中Pod之间使用虚拟二层网络连接

Kubernetes中Pod之间使用虚拟二层网络连接

Comments 0 Comment  99 Views

閱讀本文約花費: 6 (分鐘)Kubernetes中Pod之间使用虚拟二层网络连接引起的调研 传统的三层网络 在传统的大型数据中心，网络通常是三层结构。这个模型包含了以下三层： Access Layer（接入层）：有时也称为Edge Layer。接入交换机通常位于机架顶部，所以它们也被称为ToR（Top of Rack）交换机，它们物理连接服务器。 Aggregation Layer（汇聚层）：有时候也称为Distribution Layer。汇聚交换机连接Access交换机，同时提供其他的服务，例如防火墙，SSL offload，入侵检测，网络分析等。 Core Layer（核心层）：核心交换机为进出数据中心的包提供高速的转发，为多个汇聚层提供连接性，核心交换机为通常为整个网络提供一个弹性的L3路由网络。 三层网络框架示意图如下： 其中：汇聚交换机以上的为L2网络，以上是L3网络。每组汇聚交换机管理一个POD（Point Of Delivery），每个POD内都是独立的VLAN网络。服务器在POD内迁移不必修改IP地址和默认网关，因为一个POD对应一个L2广播域。 比如：同一机柜的连接的交换机叫接入交换机，连接多个接入交换机的叫汇聚交换机，它们处于同一个vlan网络。（在计算机网络中，一个二层网络可以被划分为多个不同的广播域，一个广播域对应了一个特定的用户组，默认情况下这些不同的…

Read More Read More

     
Scroll Up