Browsed by
标签: 缓存

docker常用命令

docker常用命令

閱讀本文約花費: 18 (分鐘)Docker Engine是一种开源容器化技术,用于构建和容器化您的应用程序。Docker Engine通过以下方式充当客户端-服务器应用程序: 具有长时间运行的守护进程的服务器dockerd。 API,用于指定程序可以用来与Docker守护程序进行对话和指示的接口。 命令行界面(CLI)客户端docker。 CLI使用Docker API通过脚本或直接CLI命令控制或与Docker守护程序进行交互。许多其他Docker应用程序都使用基础API和CLI。守护程序创建和管理Docker对象,例如映像,容器,网络和卷。 docker常用命令 中文版 $ docker –help Usage: docker [OPTIONS] COMMAND A self-sufficient runtime for containers一个可以独立运行的容器 Options:–config string 客户端配置文件的位置 (默认 “/home/mrdede/.docker”)-c, –context string 用于连接守护进程的上下文的名称 (使用“DOCKER上下文使用”覆盖DOCKER主机env变量和默认上下文设置)-D, –debug 启用调试模式-H, –host lis…

Read More Read More

如何Docker化任意一个应用

如何Docker化任意一个应用

閱讀本文約花費: 10 (分鐘)网上有很多关于如何将应用 Docker 化的教程,为什么我还要再写一个呢? 我见过的大部分教程都是限定在某种特定技术(例如 Java 或者 Python),可能无法满足读者的需求。同时,这些教程也没有说清楚关于 Dev 和 Ops 团队之间建立明确约定所涉及到的所有相关方面(这正是容器化的精髓所在)。 我根据最近的经验总结了以下一些步骤。它是一份细节清单,包含了其他指南中忽略的内容。 声明:这不是一份新手指南。我建议读者先掌握一些如何设置和使用 docker 的基础知识,并且创建和运行一些容器之后,再来阅读。 让我们开始吧。 一、选择基础镜像 每种对应技术几乎都有自己的基础镜像,例如: https://hub.docker.com/_/java/ https://hub.docker.com/_/python/ https://hub.docker.com/_/nginx/ 如果不能直接使用这些镜像,我们就需要从基础操作系统镜像开始安装所有的依赖。 外面有很多教程使用的都是 Ubuntu(例如 ubuntu:16.04)作为基础镜像,这不能算有问题,但是我建议优先考虑 Alpine 镜像: https://hub.docker.com/_/alpine/ 它是一个非常小的基础镜像(大约只有 5MB)。 注意:在基于 Alpine 的镜像中无法使用“a…

Read More Read More

Kubernetes 社区是如何运作的系列之一——哲学及治理

Kubernetes 社区是如何运作的系列之一——哲学及治理

閱讀本文約花費: 6 (分鐘)开源社区治理,正在逐渐的成熟,Linux、CNCF、OpenStack、Apache基金会等俨然成为软件业的中流砥柱,本土是不是应该潜心学习这些先进的管理/治理方式?精英制还是完全民主化?是不是应该以实际行动和理性思考来作出正确的判断? Mon Feb 5, 2018 | 1900 Words | 大约需要阅读 4 分钟 | | 引子 在2017年,关于容器的管理和调度平台,战火的硝烟渐渐的平息,Kubernetes 以压倒性的优势占据了这个细分领域的霸主,如下图来自 thenewstack 的调查: 如果仅仅从纯技术的角度而言,Kubernetes 和其它平台是半斤八两,处于伯仲之间,那么在社区的运营和赢得人们信任的方面,Kubernetes绝对是No.1,没有哪家能够相提并论。即使是Docker本身拥有无数拥泵的情况下,是容器的默认事实标准,也无法抵挡透明、开放、协作的Kubernetes社区的魅力。开源之道在Kubernetes 之所以成功的背后神秘力量 进行过专门的表述。 在上个月的中旬,Software Engineering Daily 的Jeff 撰写了一篇非常棒的文章:Kubernetes 的“下沉”,意指Kubernetes已经像Linux在单机操作系统的地位一样,成为分布式系统平台的默认选择。成为了分布式系统事实…

Read More Read More

kubernetes实践:Istio之策略与遥测

kubernetes实践:Istio之策略与遥测

閱讀本文約花費: 9 (分鐘)一:Istio简介 1.Istio定义 一个用来连接,管理和保护服务的开发平台。Istio提供一种简单的方式建立已部署服务网络,具备负载均衡,服务间认证和监控等功能。 而不需要改变任何服务代码。想要为服务增加对Istio的支持,只需要在环境中部署一个sidecar,使用Istio控制面板功能配置和管理代理,拦截微服务之间的所有网络通信。 2.为什么需要Istio 随着微服务出现,微服务的连接,管理和监控成为难题。Kubernetes可以处理多个容器的工作负载,但当涉及更复杂的需求时,需要像Istio这样的服务网格。 3.Istio的主要功能 a.流量管理(Pilot): 控制服务之间的流量和API调用的流向,使得调用更灵活可靠,并使网络在恶劣情况下更加健壮。 b.可观察性: 通过集成zipkin等服务,快速了解服务之间的依赖关系,以及它们之间流量的本质和流向,从而提供快速识别问题的能力。 c.策略执行(mixer): 将组织策略应用于服务之间的互动,确保访问策略得以执行,资源在消费者之间良好分配。策略的更改是通过配置网格而不是修改应用程序代码。 d.服务身份和安全(Istio-auth): 为网格中的服务提供可验证身份,并提供保护服务流量的能力,使其可以在不同可信度的网络上流转。 4.Envoy架构 a.svcA服务作为客户端点用服务端svcB,svc…

Read More Read More

微服务架构下的分布式限流方案全解析

微服务架构下的分布式限流方案全解析

閱讀本文約花費: 9 (分鐘)1.微服务限流 随着微服务的流行,服务和服务之间的稳定性变得越来越重要。缓存、降级和限流是保护微服务系统运行稳定性的三大利器。 缓存的目的是提升系统访问速度和增大系统能处理的容量,而降级是当服务出问题或者影响到核心流程的性能则需要暂时屏蔽掉,待高峰或者问题解决后再打开,而有些场景并不能用缓存和降级来解决,比如稀缺资源、数据库的写操作、频繁的复杂查询,因此需有一种手段来限制这些场景的请求量,即限流。 比如当我们设计了一个函数,准备上线,这时候这个函数会消耗一些资源,处理上限是1秒服务3000个QPS,但如果实际情况遇到高于3000的QPS该如何解决呢? 所以限流的目的应当是通过对并发访问/请求进行限速或者一个时间窗口内的的请求进行限速来保护系统,一旦达到限制速率就可以拒绝服务、等待、降级。 学习如何去实现一个分布式限流框架,首先,我们需要去了解最基本的两种限流算法。 2.限流算法 2.1漏桶算法 漏桶算法思路很简单,水(也就是请求)先进入到漏桶里,漏桶以一定的速度出水,当水流入速度过大会直接溢出,然后就拒绝请求,可以看出漏桶算法能强行限制数据的传输速率。示意图(来源网络)如下: 2.2令牌桶算法 令牌桶算法和漏桶算法效果一样但方向相反的算法,更加容易理解。随着时间流逝,系统会按恒定1/QPS时间间隔(如果QPS=100,则间隔是10ms)往桶里加入令牌(…

Read More Read More

Java 应用性能调优实践

Java 应用性能调优实践

閱讀本文約花費: 24 (分鐘)Java 应用性能优化是一个老生常谈的话题,典型的性能问题如页面响应慢、接口超时,服务器负载高、并发数低,数据库频繁死锁等。尤其是在”糙快猛”的互联网开发模式大行其道的今天,随着系统访问量的日益增加和代码的臃肿,各种性能问题开始纷至沓来。Java 应用性能的瓶颈点非常多,比如磁盘、内存、网络 I/O 等系统因素,Java 应用代码,JVM GC,数据库,缓存等。笔者根据个人经验,将 Java 性能优化分为 4 个层级:应用层、数据库层、框架层、JVM 层,如图 1 所示。 图 1.Java 性能优化分层模型 每层优化难度逐级增加,涉及的知识和解决的问题也会不同。比如应用层需要理解代码逻辑,通过 Java 线程栈定位有问题代码行等;数据库层面需要分析 SQL、定位死锁等;框架层需要懂源代码,理解框架机制;JVM 层需要对 GC 的类型和工作机制有深入了解,对各种 JVM 参数作用了然于胸。 围绕 Java 性能优化,有两种最基本的分析方法:现场分析法和事后分析法。现场分析法通过保留现场,再采用诊断工具分析定位。现场分析对线上影响较大,部分场景(特别是涉及到用户关键的在线业务时)不太合适。事后分析法需要尽可能多收集现场数据,然后立即恢复服务,同时针对收集的现场数据进行事后分析和复现。下面我们从性能诊断工具出发,分享搜狗商业平台在其中的一些案例与实践。 性…

Read More Read More

项目架构之传统三层架构和领域模型三层架构

项目架构之传统三层架构和领域模型三层架构

閱讀本文約花費: 18 (分鐘)一、工程结构 本系列文章所示范的项目基于传统三层架构进行分层,基于工作职责和Maven结构进行模块划分。本文将对传统三层架构和对应的领域模型架构、以及每个模块的职责进行简单的说明。下图即示范项目的模块结构: 二、架构之传统三层架构 传统三层架构是一种软件架构,是一种典型的、基于贫血模型的、面向过程的JavaWeb分层方式。该架构分为以下三个层次: 数据访问层(DAL – Data Access Layer)即对包括数据库在内的数据源进行操作的部分。 业务逻辑层(BLL – Business Logic Layer)即对业务数据进行逻辑处理的部分。 表现层(UI – User Interface)即与用户交互的部分。 分层的目的是为了解耦和明确责任。开发人员可以只关心自己所负责的那一层,因为他只需要知道上一层提供了哪些接口,从而利用这些接口进行编程。而上一层的开发人员在不改变接口的情况下,可以任意地替换具体的实现,从而实现松耦合。 相比更传统的架构,三层架构有着明显的优势,但也有不可忽视的缺点。初期的JavaWeb在JSP内同时进行数据库读写、业务逻辑处理和页面渲染,简单而暴力。而今的架构,在JSP之上增加了一个处理业务逻辑的中间层和一个封装了数据库操作的数据访问层,毫无疑问造成了代码量的大幅度上升和效率的下降。 本…

Read More Read More

Service Mesh架构反思:数据平面和控制平面的界线该如何划定?

Service Mesh架构反思:数据平面和控制平面的界线该如何划定?

閱讀本文約花費: 19 (分鐘)苦等一年,始终不见Istio的性能有实质性提升,失望之余,开始反思Istio而至Service Mesh的架构。焦点所在:proxy到底该做哪些事情?架构的优美和性能的实际表现该如何平衡? 问题所在 Istio的性能,从去年5月问世以来,就是一块心病。 前段时间Istio 0.7.1版本发布,不久我们得到了这个一个”喜讯”:Istio的性能在0.7.1版本中得到了大幅提升! 最大QPS从0.5.1的700,到0.6.0的1000,再到0.7.1的1700,纵向比较Istio最近的性能提升的确不错,都2.5倍性能了。 但是,注意,QPS 700/1000/1700。是的,没错,你没有看错,没有漏掉一个零或者两个零。 稍微回顾一下近年中有自己有实际感受的例子: 几个月之前写了一个基于netty4.1的HTTP转发的demo,没做任何优化和调教,轻松10万+的QPS 两年前写的dolphin框架,gRPC直连,15万QPS轻松做到 然后,白衣和隔壁老王两位同学轻描淡写的好像说过,OSP极致性能过了20万QPS了(背景补充:OSP是唯品会的服务化框架,sidecar模式,它的Proxy是被大家诟病以慢著称的Java)。 当然Istio测试场景稍微复杂一些,毕竟不是空请求,但是如论如何,从QPS十几二十万这个级别,直落到QPS一两千,中间有几乎100倍的差距。…

Read More Read More

千万级用户的大型网站,应该如何设计其高并发架构?

千万级用户的大型网站,应该如何设计其高并发架构?

閱讀本文約花費: 10 (分鐘)目录 (1)单块架构 (2)初步的高可用架构 (3)千万级用户量的压力预估 (4)服务器压力预估 (5)业务垂直拆分 (6)用分布式缓存抗下读请求 (7)基于数据库主从架构做读写分离 (8)总结 (1)单块架构 一般一个网站刚开始建立的时候,用户量是很少的,大概可能就几万或者几十万的用户量,每天活跃的用户可能就几百或者几千个。 这个时候一般网站架构都是采用单体架构来设计的,总共就部署3台服务器,1台应用服务器,1台数据库服务器,1台图片服务器。 研发团队通常都在10人以内,就是在一个单块应用里写代码,然后写好之后合并代码,接着就是直接在线上的应用服务器上发布。 很可能就是手动把应用服务器上的Tomcat给关掉,然后替换系统的代码war包,接着重新启动Tomcat。 数据库一般就部署在一台独立的服务器上,存放网站的全部核心数据。 然后在另外一台独立的服务器上部署NFS作为图片服务器,存放网站的全部图片。应用服务器上的代码会连接以及操作数据库以及图片服务器。如下图所示: (2)初步的高可用架构 但是这种纯单块系统架构下,有高可用问题存在,最大的问题就是应用服务器可能会故障,或者是数据库可能会故障 所以在这个时期,一般稍微预算充足一点的公司,都会做一个初步的高可用架构出来。 对于应用服务器而言,一般会集群化部署。当然所谓的集群化部署,在初期用户量很少的情况…

Read More Read More

Java性能优化的50个细节(珍藏版)

Java性能优化的50个细节(珍藏版)

閱讀本文約花費: 22 (分鐘)在JAVA程序中,性能问题的大部分原因并不在于JAVA语言,而是程序本身。养成良好的编码习惯非常重要,能够显著地提升程序性能。 java性能优化细节 1. 尽量在合适的场合使用单例 使用单例可以减轻加载的负担,缩短加载的时间,提高加载的效率,但并不是所有地方都适用于单例,简单来说,单例主要适用于以下三个方面: 第一,控制资源的使用,通过线程同步来控制资源的并发访问; 第二,控制实例的产生,以达到节约资源的目的; 第三,控制数据共享,在不建立直接关联的条件下,让多个不相关的进程或线程之间实现通信。 2. 尽量避免随意使用静态变量 当某个对象被定义为static变量所引用,那么GC通常是不会回收这个对象所占有的内存,如 public class A{private static B b = new B();} 此时静态变量b的生命周期与A类同步,如果A类不会卸载,那么b对象会常驻内存,直到程序终止。 3. 尽量避免过多过常地创建Java对象 尽量避免在经常调用的方法,循环中new对象,由于系统不仅要花费时间来创建对象,而且还要花时间对这些对象进行垃圾回收和处理,在我们可以控制的范围内,最大限度地重用对象,最好能用基本的数据类型或数组来替代对象。 4. 尽量使用final修饰符 带有final修饰符的类是不可派生的。在JAVA核心API中,有许多应用fin…

Read More Read More

高并发架构的设计

高并发架构的设计

閱讀本文約花費: 10 (分鐘)1、什么是高并发 1)高并发(High Concurrency)是互联网分布式系统架构设计中必须考虑的因素之一,它通常 是指,通过设计保证系统能够同时并行处理很多请求。 2)高并发相关常用的一些指标有响应时间(Response Time),吞吐量(Throughput),每秒查 询率 QPS(Query Per Second),并发用户数等。 3)响应时间:系统对请求做出响应的时间。例如系统处理一个 HTTP 请求需要 200ms,这个 200ms 就是系统的响应时间。 4)吞吐量:单位时间内处理的请求数量。 5)QPS:每秒响应请求数。在互联网领域,这个指标和吞吐量区分的没有这么明显。 6)并发用户数:同时承载正常使用系统功能的用户数量。例如一个即时通讯系统,同时在线量 一定程度上代表了系统的并发用户数。 2、如何提升系统的并发能力 互联网分布式架构设计,提高系统并发能力的方式,方法论上主要有两种:垂直扩展 (Scale Up)与水平扩展(Scale Out)。 垂直扩展:提升单机处理能力。垂直扩展的方式又有两种: 1)增强单机硬件性能,例如:增加 CPU 核数如 32 核,升级更好的网卡如万兆,升级更 好的硬盘如 SSD,扩充硬盘容量如 2T,扩充系统内存如 128G; 2)提升单机架构性能,例如:使用 Cache 来减少 IO 次数,使用异步来…

Read More Read More

一个可供参考的Java高并发异步应用案例

一个可供参考的Java高并发异步应用案例

閱讀本文約花費: 11 (分鐘) 泰康在线微信公众号系泰康在线财产保险股份有限公司旗下平台,希望可以通过持续不断的创新,提升客户对于保险的认知及体验,通过对大数据技术的应用,精准的为客户设计产品以及提供服务。泰康在线微信公众号,现有1000多万粉丝。在日常的运营中,借助于红包奖励、卡券分享、消息通知、微信分享等手段,通过好的内容,好的活动、好的产品以及相应的精准营销来增强用户的粘性和活跃度。在日常运营中,公众号会通过给用户下发营销或者科普类的消息来通知客户。 根据经验,微信消息下发后10分钟后流量会逐步上升,30分钟左右到达峰值,1个小时后会显著下降。在这个时间段内,系统的压力会很大。在系统设计和改进中,系统的很多场景使用异步进行实现,一方面能缩短主流程的时间处理,另一方面能够通过异步队列进行一定程度的削峰。今天重点介绍单个JVM内的异步优化实践,不涉及分布式时的异步优化实践。在异步执行时,可以调用远程的服务集群来实现一定的任务分解。部署示意图整个系统都部署在公有云上,虚拟机上有部署1个Nginx,4个Tomcat,Nginx使用随机的方式负载均衡到Tomcat上面。虚机之间通过LB将客户请求转发到Nginx上面负载均衡,Nginx再将请求分配到tomcat应用服务器上。由多台应用服务器,对外服务提供Rest服务,在每个Tomcat内部使用异步队列。同时由一台控制服务器,进行异步任…

Read More Read More

WebSocket从入门到精通,半小时就够!

WebSocket从入门到精通,半小时就够!

閱讀本文約花費: 27 (分鐘)自从HTML5里的WebSocket出现后,彻底改变了以往Web端即时通讯技术的基础通道这个“痛点”(在此之前,开发者们不得不弄出了诸如:短轮询、长轮询、Comet、SSE等技术,可谓苦之久矣…),如今再也不用纠结到底该用“轮询”还是“Comet”技术来保证数据的实时性了,幸福来得就是如此突然 ^-^。 WebSocket如今不仅在Web应用里使用广泛,也慢慢被开发者们应用到各种那些原本使用TCP、UDP这类协议的富客户端(比如移动端中)。 有鉴于此,对于即时通讯方向的开发者来说,全面深入的了解WebSocket是非常有必要的,面试时也少不了会考察这方面的知识。 所以,即时通讯网在建站至今的几年时间里,持续整理了一大批跟Web端即时通讯有关的技术文章(这基中尤其WebSocket方面的文章最多)。本文也是一篇关于WebSocket从入门到精通的文章,内容由浅入深,比较适合想要在短时间内较深入的了解WebSocket协议的开发者学习。 《WebSocket详解(一):初步认识WebSocket技术》 《WebSocket详解(二):技术原理、代码演示和应用案例》 《WebSocket详解(三):深入WebSocket通信协议细节》 《WebSocket详解(四):刨根问底HTTP与WebSocket的关系(上篇)》 《WebSocket详解…

Read More Read More

别让自己“墙”了自己

别让自己“墙”了自己

閱讀本文約花費: 19 (分鐘)这一两周与几个朋友聊天,有年轻的90后,也有大叔级的70后,这些人在我看来都是很有能力的人,但是一些喜好过于强烈,让我不经意地回顾了我工作20年来身边的人,有发展得好的,也有发展的不好的,有些人是很可惜的,因为限制他们的不是其它人,也不是环境,而是自己,所以,很想写下这篇文章。(注:这篇文章可能会是一篇说教的文章,所以,可能会让你看着犯困,所以,我会尽量地短一些,而且尽可能多讲故事,少道理,这里的故事,全是真实发生的) 几个故事 2019年年初,我面试了一个很年轻的小伙子(93/94年出生),这个小伙子特别有灵性,也很聪明,计算机专业出身,也很喜欢技术,基础和学习能力也很好。在我这20年来认识的人中,如果他能呆在北京、上海、深圳这样的城市,我保证不出三年,他会成为他们同龄人中非常出色的技术人员,如果有个好的舞台有一个好的团队带他,他的未来会非常成功。然而,这个小伙子有两大喜好:1)只愿(或是说被迫)呆在一个毫无IT的环境的三/四线城市,2)对技术有非常大的偏好,只喜欢Go语言,非常不喜欢其它的语言,比如:Java(离开Java的世界,基本上离开了做架构的世界(相关解释见文末))。 他的这两个喜好,足以让一个未来会很优秀的人毁掉,因为,这个时代没有限制他,他的能力也没有限制他,但是他的意识完完全全地限制了他。 他把自己最宝贵的青春放在了很烂的项目上,就…

Read More Read More

从PHP到Node,聊一聊淘宝首页背后的技术

从PHP到Node,聊一聊淘宝首页背后的技术

閱讀本文約花費: 22 (分鐘)“作者从2014年双十二结束时开始接手淘宝首页,经历了淘宝首页的两次改版和一次从PHP到Node的迁移,不久前完成了工作的交接。本文介绍了淘宝首页的变迁过程、性能优化、稳定性保障和敏捷措施,分享了作者在此过程中的感受。 相关背景介绍 淘宝首页是淘宝的门面,承载着几乎淘系所有业务的入口,流量很大,量级单位为亿。近几年无线端崛起,业务重点开始向无线终端偏移(目前不能叫偏移,基本以无线为主了),所以淘宝 PC 端首页的流量也有削减,不过即便如此,它的日均 PV 依然相当高。 淘宝首页一向是内部平台和技术的试验田,它一直在变化着。最新的框架和系统都会找淘宝首页试点,可以试想下,如果某一项需要推动的升级或者优化措施在淘宝首页已经上线,并且拿到了良好的数据和稳定性,其他业务还有什么理由不去尝试和更迭呢?同时,去年一年身在淘宝前端的技术架构组,自然而然也会主动去 push 一些实验性的内容到业务上。 淘系的站点页面包括首页、其他频道页和活动页等,这些页面并不都由淘宝前端一行一行的代码码出来,业务如此之多,这种玩法即便人数 double 也忙不过来。事实上,大多数页面都是依托内部的搭建平台一一运营或者前端通过模块搭建的方式一一构建的,而前端 focus 的重点在于搭建平台的建设自身以及模块的通用性和复用率的保障,当然,还有一些工程化的东西。 使用搭建平台搭建的页面,…

Read More Read More

企业应用架构演化探讨:从微服务到Service Mesh

企业应用架构演化探讨:从微服务到Service Mesh

閱讀本文約花費: 18 (分鐘)导读 当下微服务的实践方案中,Spring Cloud,Dubbo作为主流的落地方案,在企业应用架构中发挥越来越重要的作用。需要特别说明:本文讨论的架构目前适用于普通的企业级应用,其他行业(例如互联网)需要进一步扩展。 在讨论之前,我们需要明确一个事实:企业应用一定是围绕业务进行的。无论采用什么的架构落地,都是为了更好的为应用业务进行服务。从企业应用的特性考虑,主要包括:稳定性,安全性,扩展性,容错性。 围绕着企业应用的这些特点,我们来看一个典型的微服务企业架构模型,如图所示: 服务接入层:企业暴露到外部访问的入口,一般通过防火墙等。 网关层:服务网关是介于客户端和服务端的中间层,所有的外部请求会先经过服务网关,为企业应用提供统一的访问控制入口。服务网关是微服务架构下的服务拆分,聚合,路由,认证以及流控综合体现。 支撑服务层:为企业应用提供运行所需的支撑环境,包括注册发现,集中配置,容错限流,认证授权,日志聚合,监测告警,消息服务等 业务服务层:业务服务是企业应用的核心所在,为企业领域应用的具体实现,一般进一步拆分为基础服务(基础功能)和聚合服务(综合场景)。 平台服务层:为企业应用提供运行所需的软件资源,包括应用服务器,应用发布管理,应用镜像包管理,服务治理。 基础设施层:为企业应用提供运行所需的硬件资源,包括计算资源,网络资源,存储资源,基本的安…

Read More Read More

Scroll Up