Browsed by
标签:Redis

软件架构万字漫谈:业务架构、应用架构与云基础架构

软件架构万字漫谈:业务架构、应用架构与云基础架构

閱讀本文約花費: 34 (分鐘) 本文首先介绍了架构的分类以及架构模式与架构风格其次介绍了DDD 领域驱动设计和微服务与云原生架构,最后介绍 Kuberentes 应用,了解详情请阅读下文。本文来自于知乎,由火龙果软件Alice编辑、推荐。 软件开发就是把一个复杂的问题分解为一系列简单的问题,再把一系列简单的解决方案组合成一个复杂的解决方案。而软件开发中最大的挑战,就是即能够快速高效地针对需求、环境的变化做出改变,也能够持续提供稳定、高可用的服务。而软件架构,就是软件系统的骨骼与框架。 所谓架构,见仁见智,很难有一个明确或标准的定义;但架构并非镜花水月或阳春白雪,有系统的地方就需要架构,大到航空飞机,小到一个电商系统里面的一个功能组件,都需要设计和架构。抽象而言,架构就是对系统中的实体以及实体之间的关系所进行的抽象描述,是对物/信息的功能与形式元素之间的对应情况所做的分配,是对元素之间的关系以及元素同周边环境之间的关系所做的定义。架构能将目标系统按某个原则进行切分,切分的原则,是要便于不同的角色进行并行工作,结构良好的创造活动要优于毫无结构的创造活动。 软件架构的核心价值,即是控制系统的复杂性,将核心业务逻辑和技术细节的分离与解耦。软件架构是系统的草图,它描述的对象是直接构成系统的抽象组件;各个组件之间的连接则明确和相对细致地描述组件之间的通信。在实现阶段,这些抽象组件被细化为实际…

Read More Read More

我是Redis,MySQL大哥被我害惨了

我是Redis,MySQL大哥被我害惨了

閱讀本文約花費: 10 (分鐘)我是Redis 你好,我是Redis,一个叫Antirez的男人把我带到了这个世界上。 说起我的诞生,跟关系数据库MySQL还挺有渊源的。 在我还没来到这个世界上的时候,MySQL过的很辛苦,互联网发展的越来越快,它容纳的数据也越来越多,用户请求也随之暴涨,而每一个用户请求都变成了对它的一个又一个读写操作,MySQL是苦不堪言。尤其是到“双11”、“618“这种全民购物狂欢的日子,都是MySQL受苦受难的日子。 据后来MySQL告诉我说,其实有一大半的用户请求都是读操作,而且经常都是重复查询一个东西,浪费它很多时间去进行磁盘I/O。 后来有人就琢磨,是不是可以学学CPU,给数据库也加一个缓存呢?于是我就诞生了! 出生不久,我就和MySQL成为了好朋友,我们俩常常携手出现在后端服务器中。 应用程序们从MySQL查询到的数据,在我这里登记一下,后面再需要用到的时候,就先找我要,我这里没有再找MySQL要。 为了方便使用,我支持好几种数据结构的存储: String Hash List Set SortedSet Bitmap ······ 因为我把登记的数据都记录在内存中,不用去执行慢如蜗牛的I/O操作,所以找我要比找MySQL要省去了不少的时间呢。 可别小瞧这简单的一个改变,我可为MySQL减轻了不小的负担!随着程序的运行,我缓存的数据越来越多,有相当部…

Read More Read More

苏宁高时效、高并发秒杀业务中台的设计与实现

苏宁高时效、高并发秒杀业务中台的设计与实现

閱讀本文約花費: 20 (分鐘) 文章主要介绍了苏宁架构设计背景,苏宁的架构设计以及系统多活部署与单机房宕机场景下的降级方案 设计背景 对于苏宁易购主站而言,正常的用户购物流程囊括选品、下单、库存扣减、付款、订单状态更新、物流履约等。但是在电商业务中往往会涉及到对某些热点商品的秒杀场景。相比于正常购物流程,秒杀场景具有时效性高、并发量大、瞬时业务量极高的业务特性,往往会出现显著的分布式一致性问题。正常的业务系统不能很好地应对瞬时高并发的业务需求,因此就需要针对于秒杀场景进行相应的架构优化,抑或是设计专门用于秒杀的中台业务系统。 就秒杀业务而言,系统在瞬时会达到极高的并发量,如果与其它业务耦合,那么势必会对其它业务造成风险,因此基于安全性考虑和业务隔离原则,秒杀系统在设计上应该与其它系统充分解耦,单独部署。本文将讨论在苏宁现有的技术架构和中台组件的基础上,如何去实现一个通用型秒杀业务中台。 架构设计 1. 系统前端与负载层设计 图一:前端与负载层设计 鉴于秒杀业务本身的高并发特性,对用户请求进行前端分流是必不可少的一步。在系统上游就对部分用户请求进行处理,可以避免海量请求对后端服务器产生过大压力。因为用户往往在秒杀前几分钟就开始点击下单按钮,因此在秒杀开始前可以使用静态资源页面,用户请求由 CDN 直接响应,不必到达后端服务器。 此外,由于秒杀业务的高时效性特征,下单窗口基本集中在秒…

Read More Read More

Medium开发团队谈架构设计

Medium开发团队谈架构设计

閱讀本文約花費: 16 (分鐘) 背景   说到底,Medium是个社交网络,人们可以在这里分享有意思的故事和想法。据统计,目前累积的用户阅读时间已经超过14亿分钟,合两千六百年。   我们支持着每个月两千五百万的读者以及每周数以万计的文章发布。我们不想Medium的文章以阅读量为成功的依据,而是观点取胜。在Medium,文章的观点比作者的名头更重要。在这里,对话促进想法,并且很看重文字的力量。   我是Medium开发团队的负责人,此前在Google工作,负责开发Google+和Gmail,还创立了Closure项目。业余时间我喜欢滑雪跳伞和丛林冒险。   团队介绍   说起团队我非常自豪,这是一群富有好奇心而且想法丰富的天才,大家凑到一块是想做大事的。   团队以跨功能的任务驱动,这样每个人既可以专攻,又可以毫无压力的对整个架构有所贡献。我们的理念就是接触的方面越多,对团队的锻炼越大。更多关于团队的理念见此。   在工作组织方面,我们有着很大的自由度,当然作为一个公司组成,我们还是有季度目标的,并且鼓励敏捷开发模式。我们使用GitHub进行code review和问题跟踪,用Google Apps作为邮件、文档和表单系统。跟很多团队习惯使用Trello不同,我们是Slack和slack机器人的重度用户。   原始架构   最开始的时候,Medium部署在EC2上,用Node.j…

Read More Read More

HAProxy Nginx LVS Apache总结篇

HAProxy Nginx LVS Apache总结篇

閱讀本文約花費: 8 (分鐘)一、今天花点时间总结分享一下HAProxy、Nginx、LVS、Apache: 比较 HAProxy Nginx LVS Apache   简介 高可用、负载均衡且基于TCP和HTTP应用的代理,支持高并发,多集群反代。 高性能http和反向代理服务器、邮件代理服务器,支持高并发,轻量级Web,低系统资源消耗。 Linux虚拟服务器,常用VS/NAT、VS/TUN和VS/DR,三种模式负载均衡。 高性能Web服务器,支持代理,市场份额很高。   优点缺点 1、抗负载能力强,负载均衡速度高。2、支持session保持,Cookie引导,可通过url检测后端服务器健康状态。3、也可做MySQL、Email等负载均衡。4、一般不做Web服务器的Cache。 1、抗负载能力强。2、http、https、Emai协议功能较好,处理相应请求快。3、Web能力强,配置简单,支持缓存功能、适用动静分离,低内存消耗。4、不支持session直接保持,但可通过ip_hash解决,通过端口对后端服务器健康检查。 1、抗负载能力强。2、通过vrrp转发(仅分发)效率高,流量通过内核处理,没有流量产生。(理论)3、相当稳定可靠。4、不支持正则,不能做动静分离,配置略复杂,需要IP略多。 1、Web处理能力强,市场份额很高。(不过后期Ngi…

Read More Read More

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

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

閱讀本文約花費: 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

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

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

閱讀本文約花費: 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

云上 ARM 实例应用优化之我见

云上 ARM 实例应用优化之我见

閱讀本文約花費: 22 (分鐘) 亚马逊AWS官方博客 发布于:2020 年 8 月 10 日 10:00 ARM 处理器的崛起 过去两个月的科技媒体上关于 ARM 芯片的新闻可谓是高潮迭起,不断的引起人们的关注。 首先是在 5 月 11 日,AWS 宣布了基于自研的 Graviton 2 处理器(使用了 ARM Neoverse N1 核心)的第六代 EC2 实例 – M6g 正式发布。这似乎揭开了云计算市场上 ARM 处理器大规模应用的的序幕。 紧接着,在今年 6 月 23 日的 WWDC 大会上,Apple 公司宣布了一个影响深远的决定: 计划从 2020 年年底开始,Mac 计算机将会从 Intel 芯片过渡到使用基于 ARM 的自研芯片。也许我们要问,ARM 处理器将将会在桌面设备上复制移动设备的成功吗? 第三则新闻是关于高性能计算。6 月 22 日发表的最新的一期 TOP500 榜单上,日本的 Fugaku 系统以 415.5 千万亿次浮点运算的高性能 LINPAC 成绩成为 TOP500 的第一名。而令人惊讶的是这是第一个使用 ARM 处理器的高性能处理系统。 林林总总,即使我们是半导体行业的门外汉也不难得出一个结论 – ARM 处理器不仅仅统治了手机、嵌入式应用这些传统的优势领域,或将在桌面系统、高性能计算尤其是云计算领域扮演越来越重要的角色。 EC2 上的 ARM…

Read More Read More

docker cheatsheet

docker cheatsheet

閱讀本文約花費: 1 (分鐘)Docker Cheat Sheet Build Build an image from the Dockerfile in the current directory and tag the image docker build -t myimage:1.0 . List all images that are locally stored with the Docker Engine docker image ls Delete an image from the local image store docker image rm alpine:3.4 Share Run Run a container from the Alpine version 3.9 https://www.docker.com/sites/default/files/d8/2019-09/docker-cheat-sheet.pdf List Of Docker Commands: Cheat Sheet Docker CheatSheet | Docker 配置与实践清单 https://cloud.tencent.com/developer/article/1395434 Docker CLI cheatsheet https://devhints.io/docker …

Read More Read More

ZooKeeper实际应用案例-开发实战

ZooKeeper实际应用案例-开发实战

閱讀本文約花費: 12 (分鐘) 本文主要介绍通过实际工作中的一个例子,讲解zookeeper是如何帮我解决分布式问题,以此引导大家发现自己系统中可以应用zookeeper的场景。 项目背景介绍 首先给大家介绍一下本文描述项目的情况。这是一个检索网站,它让你能在几千万份复杂文档数据中检索出你所需要的文档数据。为了加快检索速度,项目的数据分布在100台机器的内存里,我们称之为数据服务器。除了数据,这100台机器上均部署着检索程序。这些server之外,还有数台给前端提供接口的搜索server,这些机器属一个集群,我们称之为检索服务器。当搜索请求过来时,他们负责把搜索请求转发到那100台机器,待所有机器返回结果后进行合并,最终返回给前端页面。结构如下图: 面临问题 网站上线之初,由于数据只有几百万,所以数据服务器只有10多台。是一个规模比较小的分布式系统,当时没有做分布式系统的协调,也能正常工作,偶尔出问题,马上解决。但是到了近期,机器增长到100台,网站几乎每天都会出现问题,导致整个分布式系统挂掉。问题原因如下: 数据服务器之前没有做分布式协调。对于检索服务器来说,并不知道哪些数据服务器还存活,所以检索服务器每次检索,都会等待100台机器返回结果。但假如100台数据服务中某一台死掉了,检索服务器也会长时间等待他的返回。这导致了检索服务器积累了大量的请求,最终被压垮。当所有的检索服务器…

Read More Read More

微服务网关

微服务网关

閱讀本文約花費: 14 (分鐘) 本文阐述微服务的API网关的一些主要功能,并例举了几种常用的网关,最后结合spring cloud微服务框架对网关做一些简要的论述。 一、前言 随着微服务的兴起,基于其业务耦合性低、负载能力强、服务边界清晰等优点,大家纷纷使用微服务架构来实现新系统或进行老系统的改造。微服务在带来诸多好处的同时,也有一些问题需要解决,比如:如何做到有效拆分、减少服务间调用,如何统一管理所有服务的接口,如何进行自动化部署等。本文阐述微服务的API网关的一些主要功能,并例举了几种常用的网关,最后结合spring cloud微服务框架对网关做一些简要的论述。 二、API网关简介 API网关,顾名思义,是统一管理API的一个网络关口、通道,是整个微服务平台所有请求的唯一入口,所有的客户端和消费端都通过统一的网关接入微服务,在网关层处理所有的非业务功能。下图为微服务架构的简单示意图,网关起到的作用一目了然。 三、API网关的作用 为微服务云平台提供统一的入口是API网关最主要的用途,除此之外,网关还可承担认证授权、访问控制、路由、负载均衡、缓存、日志、限流限额、转换、映射、过滤、熔断、注册、服务编排、API管理、监控、统计分析等等非业务性的功能。 所以实现或者选择一个好的API网关,是建设容器云和微服务体系中一个至关重要的事项。这也决定了API网关的部署,要尽可能的减少接触面…

Read More Read More

【K8S】基于Docker+K8S+GitLab/SVN+Jenkins+Harbor搭建持续集成交付环境(环境搭建篇)

【K8S】基于Docker+K8S+GitLab/SVN+Jenkins+Harbor搭建持续集成交付环境(环境搭建篇)

閱讀本文約花費: 51 (分鐘)环境搭建概述 1.K8S是什么? K8S全称是Kubernetes,是一个全新的基于容器技术的分布式架构领先方案,基于容器技术,目的是实现资源管理的自动化,以及跨多个数据中心的资源利用率的最大化。 如果我们的系统设计遵循了kubernetes的设计思想,那么传统系统架构中那些和业务没有多大关系的底层代码或功能模块,都可以使用K8S来管理,我们不必再费心于负载均衡的选型和部署实施问题,不必再考虑引入或自己开发一个复杂的服务治理框架,不必再头疼与服务监控和故障处理模块的开发。总之,使用kubernetes提供的解决方案,会大大减少开发成本,同时可以将精力更加集中于业务本身,而且由于kubernetes提供了强大的自动化机制,所以系统后期的运维难度和运维成本大幅降低。 2.为什么要用K8S? Docker 这个新兴的容器化技术当前已经被很多公司所采用,其从单机走向集群已成必然,而云计算的蓬勃发展正在加速这一进程。Kubernetes 作为当前唯一被业界广泛认可和看好的 Docker 分布式系统解决方案。可以预见,在未来几年内,会有大量的新系统选择它,不管是运行在企业本地服务器上还是被托管到公有云上。 3.使用K8S有哪些好处? 使用Kubernetes就是在全面部署微服务架构。微服务架构的核心就是将一个巨大的单体应用分解为很多小的互相连接的微服务,一个微服…

Read More Read More

线程池运用不当的一次线上事故

线程池运用不当的一次线上事故

閱讀本文約花費: 11 (分鐘)在高并发、异步化等场景,线程池的运用可以说无处不在。线程池从本质上来讲,即通过空间换取时间,因为线程的创建和销毁都是要消耗资源和时间的,对于大量使用线程的场景,使用池化管理可以延迟线程的销毁,大大提高单个线程的复用能力,进一步提升整体性能。 今天遇到了一个比较典型的线上问题,刚好和线程池有关,另外涉及到死锁、jstack命令的使用、JDK不同线程池的适合场景等知识点,同时整个调查思路可以借鉴,特此记录和分享一下。 01 业务背景描述 该线上问题发生在广告系统的核心扣费服务,首先简单交代下大致的业务流程,方便理解问题。 绿框部分即扣费服务在广告召回扣费流程中所处的位置,简单理解:当用户点击一个广告后,会从C端发起一次实时扣费请求(CPC,按点击扣费模式),扣费服务则承接了该动作的核心业务逻辑:包括执行反作弊策略、创建扣费记录、click日志埋点等。 02 问题现象和业务影响 12月2号晚上11点左右,我们收到了一个线上告警通知:扣费服务的线程池任务队列大小远远超出了设定阈值,而且队列大小随着时间推移还在持续变大。详细告警内容如下: 相应的,我们的广告指标:点击数、收入等也出现了非常明显的下滑,几乎同时发出了业务告警通知。其中,点击数指标对应的曲线表现如下: 该线上故障发生在流量高峰期,持续了将近30分钟后才恢复正常。 03 问题调查和事故解决过程 下面…

Read More Read More

基于 Docker 和 Kubernetes 的微服务实践

基于 Docker 和 Kubernetes 的微服务实践

閱讀本文約花費: 12 (分鐘) 本文来自微信公众号,本文介绍基于Docker和Kubernetes的整个微服务实践过程,我们在实践微服务过程中做了9件重要的事情, 简化了操作流程,提高了工作效率。 一、微服务化 微服务架构 微服务 是将单一的应用程序拆分成多个微小的服务,各个小服务之间松耦合,高内聚,每个小的服务可以单独进行开发,不依赖于具体的编程语言,也可以使用不同的数据存储技术,各个服务可以独立部署,拥有各自的进程,相互之间通过轻量化的机制进行通信(如基于HTTP的API接口),所有的服务共同实现具体的业务功能。 客户端与服务端通信有2种方式,第一种是客户端直接与各个微服务进行通信,这样的架构有4个缺点: (1)多次服务请求,效率低; (2)对外暴露服务接口; (3)接口协议无法统一; (4)客户端代码复杂,服务端升级困难。 第二种方式是由API网关统一代理各个服务,对外提供统一的接口协议,该架构有3 个优势: (1)封装服务接口细节,减少通信次数; (2)统一通信协议,减少客户端代码耦合; (3)统一鉴权,流控,防攻击; 在该架构下,网关也有可能成为系统瓶颈。 相应地,这2种架构也带来了2种服务注册发现的方式,第一种是客户端通过向服务的注册中心查询微服务的地址与其通信,第二种是增加统一的API网关来查询。前者会增加客户端的复杂度,开发成本高,第二种操作会显得更加简洁,因此我…

Read More Read More

Redis的内存和实现机制

Redis的内存和实现机制

閱讀本文約花費: 23 (分鐘)1. Reids内存的划分# 数据 内存统计在used_memory中 进程本身运行需要内存 Redis主进程本身运行需要的内存占用,代码、常量池等 缓冲内存,客户端缓冲区、复制积压缓冲区、AOF缓冲区。有jemalloc分配内存,会统计在used_memory中 内存碎片 Redis在分配、回收物理内存过程中产生的。内存碎片不会统计在used_memory中。如果Redis服务器中的内存碎片已经很大,可以通过安全重启的方式减小内存碎片:因为重启之后,Redis重新从备份文件中读取数据,在内存中进行重排,为每个数据重新选择合适的内存单元,减小内存碎片。 2. Redis的数据存储的细节# 涉及到内存分配器jemalloc, 简单动态字符串(SDS),5种值类型对象的内部编码,redisObject, DictEntry: Redis 是key-value数据库,因此对每个键值对都会有一个dictEntry,里面存储了指向Key和Value的指针;next指向下一个dictEntry,与本Key-Value无关 Key: 并不是以字符串存储,而是存储在SDS结构中 RedisObject: 5种值对象不是直接以对应的类型存储的,而是被封装为redisObject来存储 jemalloc: 无论是DictEntry对象,还是redisObject, SD…

Read More Read More

AWS Solution Architecture Associate 认证攻略

AWS Solution Architecture Associate 认证攻略

閱讀本文約花費: 55 (分鐘)AWS认证介绍 AWS Certified Solutions Architect 系列认证是亚马逊从2013年开始推出的对云计算架构师能力的官方认证。考试不仅考察应试者对AWS相关云服务的熟悉程度,题目也多来源于实际中要解决的问题,要求应试者有全面的架构设计经验和积累,所以含金量很高。在美国招聘网站glassdoor上,AWS solution architect的身价平均在10万美金以上,可见业界对这个认证的认可程度。 它在国内的认可程度如何呢?根据我和考试认证中心的工作人员聊天打听到,国内来考试的分两类人,一类是工作单位和亚马逊有合作关系,单位出钱要求通过。另一类是云计算这个行业的早起的鸟儿,他们想充实自己的职业技能,在云计算这个浪潮中能有一席之地。所以相对来说了解和报考的人还是少数。 不过想顺利通过这个考试并不容易。一方面考试全程英文阅读量大。另一方面复习资料缺乏,只能通过官方的FAQ文档和白皮书进行学习,自学效率非常低。对于初次接触AWS云服务认证的同学来说,不花2,3个月的时间认证准备,是很难通过的。就算作者身边那些有2,3年AWS云服务使用经验的架构师,想裸考通过,成功率也几乎为零。所以,打算通过这个考试,一定要认真对待,规划好时间充分准备。 关于AWS认证考试更多的介绍,大家还可以参考网上刘涛同学的文章http://www.csdn….

Read More Read More

Scroll Up