Browsed by
标签: 域名

Session不香吗,为什么还要Token?

Session不香吗,为什么还要Token?

閱讀本文約花費: 16 (分鐘)我发现网上很多文章对 token 的介绍有误,所以对 cookie,session,token 作了一下对比(文中 token 指 jwt token)相信大家看完肯定有收获! Cookie 1991 年 HTTP 0.9 诞生了,当时只是为了满足大家浏览 Web 文档的要求 ,所以只有 GET 请求,浏览完了就走了,两个连接之间是没有任何联系的,这也是 HTTP 为无状态的原因,因为它诞生之初就没有这个需求。 但随着交互式 Web 的兴起(所谓交互式就是你不光可以浏览,还可以登录,发评论,购物等用户操作的行为),单纯地浏览 Web 已经无法满足人们的要求。 比如随着网上购物的兴起,需要记录用户的购物车记录,就需要有一个机制记录每个连接的关系,这样我们就知道加入购物车的商品到底属于谁了,于是 Cookie 就诞生了。 Cookie,有时也用其复数形式 Cookies。类型为“小型文本文件”,是某些网站为了辨别用户身份,进行 Session 跟踪而储存在用户本地终端上的数据(通常经过加密),由用户客户端计算机暂时或永久保存的信息 。 工作机制如下: 以加入购物车为例,每次浏览器请求后 server 都会将本次商品 id 存储在 Cookie 中返回给客户端,客户端会将 Cookie 保存在本地,下一次再将上次保存在本地的 Cookie 传给 serve…

Read More Read More

带你了解负载均衡

带你了解负载均衡

閱讀本文約花費: 7 (分鐘)相信很多小伙伴的公司都是服务治理,自动化运维了吧,那么我们很多东西都变成我们自己去设置了,比如自己创建一个域名,绑定他的代理机器,它的web负载均衡这些东西。所以今天跟大家一起来看看负载均衡。 你怎么看负载均衡 负载均衡是高可用网络基础架构的关键组件,通常用于将工作负载分布到多个服务器来提高网站、应用、数据库或其他服务的性能和可靠性。 相信很多小伙伴,一听到负载均衡四个字,第一个想到就是我们所说的Nginx吧,因为这个是离我们开发比较近的一个组件了。 第二个呢?就是我们Springcloud的组件中自带了负载均衡(ribbon),这个也是离我们开发比较近的 第三个?就是其实我们k8s里面的服务也是能做负载均衡的,目前主流容器使用方式 第四个就是我们DNS之后的一个负载均衡了SLB(这个之前运费负责的多点) 为啥要负载均衡呢? 大家看下面的图,当我们访问一个网站的时候,如果突然的流量增加,就会导致我们的服务不可用(单点故障) image.png 一个没有负载均衡的 web 架构类似下面这样: image.png 所以为了解决单点问题我们需要负载均衡(也是我们高可用,高性能,高并发的基石) 有负载均衡的架构 image.png web架构 image.png 聊聊SLB image.png 相信很多公司都有用到吧。 负载均衡的组成 负载均衡实例 (Inst…

Read More Read More

K8S Service类型

K8S Service类型

閱讀本文約花費: 5 (分鐘)K8S Service类型∶ ● K8S 的服务 (Service)用于解决K8S 集群的网络负载分配1.服务通过标签检索出正在运行的Pod,维护着该服务的可用Endpoints集合(kubectl get ep )2.服务以短名字注册到集群DNS,配合namespace和svc后缀就可以进行常规DNS查询,得到该服务的唯一ClusterIP 3.如果是Headless类型的服务,K8S不分配ClusterIP,其DNS响应为一组Pod IP列表,或者一个CNAME指向外部域名4.服务的网络实现在TCP/IP四层,通过DNAT(nodePort)或 DNAT(ClusterIP,port)两条路径之一到Pod的targetPort5.targetPort通常是Pod内工作容器或sidecar(比如envoy代理)容器监听的端口号,需要跟pod定义保持一致 ● ClusterIP类型的服务 -集群内部互访集群内部任一 pod 可以经由 ClusterlP∶port发起访问的K8S服务类型 K8S服务IP即 ClusterIP,仅存在于转发规则里,不配置到任何内核网络接口- 在 ClusterIP类型 Service的定义中∶1.无需显式指定IP,K8S将自动分配一个独占的ClusterIP,定义type为ClusterIP,也可以省略2.需要显式指定一组…

Read More Read More

The Twelve-Factor App

The Twelve-Factor App

閱讀本文約花費: 3 (分鐘)III. 配置 在环境中存储配置 通常,应用的 配置 在不同 部署 (预发布、生产环境、开发环境等等)间会有很大差异。这其中包括: 数据库,Memcached,以及其他 后端服务 的配置 第三方服务的证书,如 Amazon S3、Twitter 等 每份部署特有的配置,如域名等 有些应用在代码中使用常量保存配置,这与 12-Factor 所要求的代码和配置严格分离显然大相径庭。配置文件在各部署间存在大幅差异,代码却完全一致。 判断一个应用是否正确地将配置排除在代码之外,一个简单的方法是看该应用的基准代码是否可以立刻开源,而不用担心会暴露任何敏感的信息。 需要指出的是,这里定义的“配置”并不包括应用的内部配置,比如 Rails 的 config/routes.rb,或是使用 Spring 时 代码模块间的依赖注入关系 。这类配置在不同部署间不存在差异,所以应该写入代码。 另外一个解决方法是使用配置文件,但不把它们纳入版本控制系统,就像 Rails 的 config/database.yml 。这相对于在代码中使用常量已经是长足进步,但仍然有缺点:总是会不小心将配置文件签入了代码库;配置文件的可能会分散在不同的目录,并有着不同的…

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

深入解读Service Mesh背后的技术细节

深入解读Service Mesh背后的技术细节

閱讀本文約花費: 14 (分鐘)一、Service Mesh是Kubernetes支撑微服务能力拼图的最后一块 在上一篇文章为什么 kubernetes 天然适合微服务中我们提到,Kubernetes是一个奇葩所在,他的组件复杂,概念复杂,在没有实施微服务之前,你可能会觉得为什么Kubernetes要设计的这么复杂,但是一旦你要实施微服务,你会发现Kubernetes中的所有概念,都是有用的。 在我们微服务设计的是个要点中,我们会发现Kubernetes都能够有相应的组件和概念,提供相应的支持。 其中最后的一块拼图就是服务发现,与熔断限流降级。 众所周知,Kubernetes的服务发现是通过Service来实现的,服务之间的转发是通过kube-proxy下发iptables规则来实现的,这个只能实现最基本的服务发现和转发能力,不能满足高并发应用下的高级的服务特性,比较SpringCloud和Dubbo有一定的差距,于是Service Mesh诞生了,他期望讲熔断,限流,降级等特性,从应用层,下沉到基础设施层去实现,从而使得Kubernetes和容器全面接管微服务。 二、以Istio为例讲述Service Mesh中的技术关键点 就如SDN一样,Service Mesh将服务请求的转发分为控制面和数据面,因而分析他,也是从数据面先分析转发的能力,然后再分析控制面如何下发命令。今天这篇…

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

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

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

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

Read More Read More

Cgroup和Namespace在测试中的使用(下)

Cgroup和Namespace在测试中的使用(下)

閱讀本文約花費: 7 (分鐘)Namespace介绍 使用Namespace又叫做命名空间,可以让每个进程组具有独立的PID、IPC和网络空间等,也就是说这些系统资源不再是全局性的,而是属于特定的Namespace,每个Namespace里面的资源对其他Namespace都是透明的,从而达到资源的隔离效果。 目前namespace的种类如下分类 系统调用参数Mount namespaces CLONE_NEWNSUTS namespaces CLONE_NEWUTSIPC namespaces CLONE_NEWIPCPID namespaces CLONE_NEWPIDNetwork namespaces CLONE_NEWNETUser namespaces CLONE_NEWUSER 可以查看自己的系统支持哪些namespace# ls -lai /proc/1/nstotal 0418834 dr-x–x–x 2 root root 0 Jul 30 22:58 .1301 dr-xr-xr-x 9 root root 0 Jul 25 22:46 ..41885…

Read More Read More

微信、陌陌等著名IM软件设计架构详解

微信、陌陌等著名IM软件设计架构详解

閱讀本文約花費: 13 (分鐘)对微信、陌陌等进行了分析,发出来分享一下(时间有些久了) 电量:对于移动设备最大的瓶颈就是电量了。因为用户不可能随时携带电源,充电宝。所以必须考虑到电量问题。那就要检查我们工程是不是有后台运行,心跳包发送时间是不是合理。 流量:对于好多国内大部分屌丝用户来说可能还是包月30M,那么我们必须站在广大用户角度来考虑问题了。一个包可以解决的就一个包。 网络: 这个也是IM最核心的内容了,我们要做到在任何网络下等顺畅聊天那就不容易了,好多公司都用的xmpp框架,如果在强网络环境下,xmpp完全没有问题。但是那种弱网络环境下xmpp就束手无策啦,用户体验就很垃圾了。 个人觉得xmpp 可以玩玩(参考看这个RFC3920和RFC3921), 但是用来真正的产品就差远了。如果遇到一个做IM 的朋友张口闭口都说xmpp 的话,那么不用沟通了,肯定不是什么好产品。微信、QQ以前也曾用过xmpp,但是最后也放弃了xmpp,就知道xmpp有很多弊端了,还有就是报文太大,好臃肿,浪费流量。为了保证稳定,微信用了长链接和短链接相结合,例如: 1 、两个域名 微信划分了http模式(short链接)和 tcp 模式(long 链接),分别应对状态协议和数据传输协议 long.weixin.qq.com  dns che…

Read More Read More

WordPress文章和页面的区别

WordPress文章和页面的区别

閱讀本文約花費: 4 (分鐘)默认情况下,Wordpress提供了2种方式供我们写作内容,文章和页面,虽然说两者外观上并没有什么区别,但是从其他方面来说,还是有很多不同的,在为网站添加内容时,文章和页面的选择也非常重要 如果你是刚刚接触Wordpress的朋友,对于哪些内容该使用页面,哪些内容使用文章是非常困惑的,所以为了帮助大家更清晰的了解文章和页面的使用情景,本文将详细介绍WordPress中文章和页面的区别 WordPress文章和页面的差异 – 时间 WordPress文章有具体的发布日期,一般会显示在文章的标签上,如果你打算写一个非常普通的文章,比如博客、记录之类的,你应该使用文章。 WordPress页面则并不会显示发布日期,大多数的页面内容并不会受时间的影响,非常常见的2种页面就是联系页面和关于页面,这是我们希望用户随时都能看到的内容,并且长期有效 首页展示 如果你是采用的WordPress默认的博客布局,也就是首页显示最新文章,你会发现所有新发布的文章都会展示在首页,而页面则不会展示在首页,页面默认情况下是不会被人发现的,除非你将把它添加到菜单,或者用链接指向它 这里我们可以用它的特性做一些特别的页面,比如你可以创建一个独立页面,只想要特定的人访问,单独发给它们链接,不在首页放入口 页面和文章的组织:分类、标签和子页面 当你创建一篇博文时,你可以选择添加分类、标签 …

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

四层和七层负载均衡的区别

四层和七层负载均衡的区别

閱讀本文約花費: 33 (分鐘)(一) 简单理解四层和七层负载均衡: ① 所谓四层就是基于IP+端口的负载均衡;七层就是基于URL等应用层信息的负载均衡;同理,还有基于MAC地址的二层负载均衡和基于IP地址的三层负载均衡。 换句换说,二层负载均衡会通过一个虚拟MAC地址接收请求,然后再分配到真实的MAC地址;三层负载均衡会通过一个虚拟IP地址接收请求,然后再分配到真实的IP地址;四层通过虚拟IP+端口接收请求,然后再分配到真实的服务器;七层通过虚拟的URL或主机名接收请求,然后再分配到真实的服务器。   ② 所谓的四到七层负载均衡,就是在对后台的服务器进行负载均衡时,依据四层的信息或七层的信息来决定怎么样转发流量。 比如四层的负载均衡,就是通过发布三层的IP地址(VIP),然后加四层的端口号,来决定哪些流量需要做负载均衡,对需要处理的流量进行NAT处理,转发至后台服务器,并记录下这个TCP或者UDP的流量是由哪台服务器处理的,后续这个连接的所有流量都同样转发到同一台服务器处理。七层的负载均衡,就是在四层的基础上(没有四层是绝对不可能有七层的),再考虑应用层的特征,比如同一个Web服务器的负载均衡,除了根据VIP加80端口辨别是否需要处理的流量,还可根据七层的URL、浏览器类别、语言来决定是否要进行负载均衡。举个例子,如果你的Web服务器分成两组,一组是中文语言的…

Read More Read More

负载均衡基础知识

负载均衡基础知识

閱讀本文約花費: 18 (分鐘)一、什么是负载均衡?  互联网早期,业务流量比较小并且业务逻辑比较简单,单台服务器便可以满足基本的需求;但随着互联网的发展,业务流量越来越大并且业务逻辑也越来越复杂,单台机器的性能问题以及单点问题凸显了出来,因此需要多台机器来进行性能的水平扩展以及避免单点故障。但是要如何将不同的用户的流量分发到不同的服务器上面呢?  早期的方法是使用DNS做负载,通过给客户端解析不同的IP地址,让客户端的流量直接到达各个服务器。但是这种方法有一个很大的缺点就是延时性问题,在做出调度策略改变以后,由于DNS各级节点的缓存并不会及时的在客户端生效,而且DNS负载的调度策略比较简单,无法满足业务需求,因此就出现了负载均衡。  客户端的流量首先会到达负载均衡服务器,由负载均衡服务器通过一定的调度算法将流量分发到不同的应用服务器上面,同时负载均衡服务器也会对应用服务器做周期性的健康检查,当发现故障节点时便动态的将节点从应用服务器集群中剔除,以此来保证应用的高可用。  负载均衡又分为四层负载均衡和七层负载均衡。四层负载均衡工作在OSI模型的传输层,主要工作是转发,它在接收到客户端的流量以后通过修改数据包的地址信息将流量转发到应用服务器。  七层负载均衡工作在OSI模型的应用层,因为它需要解析应用层流量,所以七层负载均衡在接到客户端的流量以后,还需要一个完整的TCP/IP协议栈。…

Read More Read More

云计算术语(中英文对照)

云计算术语(中英文对照)

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

Scroll Up