Skip to main content

Home/ Larvata/ Group items tagged 机制

Rss Feed Group items tagged

張 旭

Kubernetes 架构浅析 - 0 views

  • 将Loadbalancer改造成Smart Loadbalancer,通过服务发现机制,应用实例启动或者销毁时自动注册到一个配置中心(etcd/zookeeper),Loadbalancer监听应用配置的变化自动修改自己的配置。
  • Mysql计划该成域名访问方式,而不是ip。为了避免dns变更时的延迟问题,需要在内网架设私有dns。
  • 配合服务发现机制自动修改dns
  • ...23 more annotations...
  • 通过增加一层代理的机制实现
  • 操作系统和基础库的依赖允许应用自定义
  • 对磁盘路径以及端口的依赖通过Docker运行参数动态注入
  • Docker的自定义变量以及参数,需要提供标准化的配置文件
  • 每个服务器节点上要有个agent来执行具体的操作,监控该节点上的应用
  • 还要提供接口以及工具去操作。
  • 应用进程和资源(包括 cpu,内存,磁盘,网络)的解耦
  • 服务依赖关系的解耦
  • scheduler在Kubernetes中是一个plugin,可以用其他的实现替换(比如mesos)
  • 大多数接口都是直接读写etcd中的数据。
  • etcd 作为配置中心和存储服务
  • kubelet 主要包含容器管理,镜像管理,Volume管理等。同时kubelet也是一个rest服务,和pod相关的命令操作都是通过调用接口实现的。
  • kube-proxy 主要用于实现Kubernetes的service机制。提供一部分SDN功能以及集群内部的智能LoadBalancer。
  • Pods Kubernetes将应用的具体实例抽象为pod。每个pod首先会启动一个google_containers/pause docker容器,然后再启动应用真正的docker容器。这样做的目的是为了可以将多个docker容器封装到一个pod中,共享网络地址。
  • Replication Controller 控制pod的副本数量
  • Services service是对一组pods的抽象,通过kube-proxy的智能LoadBalancer机制,pods的销毁迁移不会影响services的功能以及上层的调用方。
  • Namespace Kubernetes中的namespace主要用来避免pod,service的名称冲突。同一个namespace内的pod,service的名称必须是唯一的。
  • Kubernetes的理念里,pod之间是可以直接通讯的
  • 需要用户自己选择解决方案: Flannel,OpenVSwitch,Weave 等。
  • Hypernetes就是一个实现了多租户的Kubernetes版本。
  • 如果运维系统跟不上,服务拆太细,很容易出现某个服务器的角落里部署着一个很古老的不常更新的服务,后来大家竟然忘记了,最后服务器迁移的时候给丢了,用户投诉才发现。
  • 在Kubernetes上的微服务治理框架可以一揽子解决微服务的rpc,监控,容灾问题
  • 同一个pod的多个容器定义中没有优先级,启动顺序不能保证
張 旭

也许,DOM 不是答案 - 阮一峰的网络日志 - 0 views

  • 如果将来有一天,Web app会成为主流,一定有一个前提,那就是它的性能可以赶上Native app
  • Web app输给Native app的地方,不是界面(UI),而是操作性能
  • Web基于DOM,而DOM很慢。浏览器打开网页时,需要解析文档,在内存中生成DOM结构,如果遇到复杂的文档,这个过程是很慢的。可以想象一下,如果网页上有上万个、甚至几十万个形状(不管是图片或CSS),生成DOM需要多久?更不要提与其中某一个形状互动了。
  • ...10 more annotations...
  • 所有的DOM操作都是同步的,会堵塞浏览器。JavaScript操作DOM时,必须等前一个操作结束,才能执行后一个操作。
  • 浏览器重绘网页的频率是60FPS(即16毫秒/帧),JavaScript做不到在16毫秒内完成DOM操作,因此产生了跳帧。
  • 没有使用DOM,而是将整个网站用canvas输出
  • canvas可以被硬件加速
  • 主要是canvas只是一个位图,本身没有语义,如果要在它上面实现UI,等于HTML语言已有的东西都要再发明一遍,比如如何实现超链接、如何实现CSS效果等等。
  • canvas不是自适应的(responsive),文字在哪里断行,都要自己计算,而且用户也无法选中文本
  • 多线程浏览器
  • DOM的异步操作。JavaScript对DOM的操作不再是同步的,而是触发后,交给Event Loop机制进行监听。
  • 用数据库取代DOM
  • 非DOM方案。浏览器不再将网页处理成DOM结构,而是变为其他结构
張 旭

单表60亿记录等大数据场景的MySQL优化和运维之道 - 快课网 - 0 views

  • 存储引擎使用InnoDB
  • 变长字符串尽量使用varchar varbinary
  • 不在数据库中存储图片、文件等
  • ...34 more annotations...
  • 库名、表名、字段名、索引名使用小写字母,以下划线分割 ,需要见名知意
  • 所有字段均定义为NOT NULL ,除非你真的想存Null
  • 使用TIMESTAMP存储时间
  • 使用DECIMAL存储精确浮点数,用float有的时候会有问题
  • 单个索引字段数不超过5,单表索引数量不超过5,索引设计遵循B+ Tree索引最左前缀匹配原则
  • 建立的索引能覆盖80%主要的查询,不求全,解决问题的主要矛盾
  • 避免冗余索引
  • 索引这个东西是一把双刃剑,在加速读的同时也引入了很多额外的写入和锁,降低写入能力
  • 字段定义为varchar,但传入的值是个int,就会导致全表扫描,要求程序端要做好类型检查
  • 避免使用大表的JOIN,MySQL优化器对join优化策略过于简单
  • UPDATE、DELETE语句不使用LIMIT ,容易造成主从不一致
  • 高危操作检查,Drop前做好数据备份
  • 日志分析,主要是指的MySQL慢日志和错误日志
  • Percona公司根据Facebook OSC思路,用perl重写了一版,就是我们现在用得很多的pt-online-schema-change,软件本身非常成熟,支持目前主流版本
  • 原生主从同步肯定存在着性能和安全性问题
  • Sharding is very complex, so itʼs best not to shard until itʼs obvious that you will actually need to!
  • 有中间层控制拆分逻辑最好,否则拆分过细管理成本会很高
  • 全量binlog备份
  • xtrabackup热备
  • 采用分布式文件系统存储备份
  • 基于库级别的复制,所以如果你只有一个库,使用这个意义不大
  • 半同步复制,从5.5开始支持
  • 半同步通过从库返回ACK这种方式确认从库收到数据
  • Secondsbehindmaster来判断延时不可靠,在网络抖动或者一些特殊参数配置情况下,会造成这个值是0但其实延时很大了。通过heartbeat表插入时间戳这种机制判断延时是更靠谱的
  • Binlog格式,建议都采用row格式,数据一致性更好
  • 成熟开源事务存储引擎,支持ACID,支持事务四个隔离级别,更好的数据安全性,高性能高并发,MVCC,细粒度锁,支持O_DIRECT
  • 数据安全性至关重要,InnoDB完胜
  • 主流使用TokuDB主要是看中了它的高压缩比
  • TokuDB在测试过程中写入稳定性是非常好的
  • 单表容量在InnoDB下1TB+,使用Tokudb的lzma压缩到80GB
  • 独立写程序好一些,与程序解耦方便后期维护
  • 追踪字段值变化可以通过分析row格式binlog好一些
  • 解决了单表过大恢复时间问题,也支持online DDL
  • 物理备份采用xtrabackup热备方案比较好
張 旭

我所认为的RESTful API最佳实践 · ScienJus's Blog - 0 views

  • 最好将过滤、分页和排序的相关信息全权交给客户端,包括过滤条件、页数或是游标、每页的数量、排序方式、升降序等,这样可以使 API 更加灵活。
  • 过度纠结如何遵守规范只是徒增烦恼
  • API 的版本号和客户端 APP 的版本号是毫无关系的
  • ...13 more annotations...
  • 除了 POST 其他三种请求都具备幂等性(多次请求的效果相同)
  • PUT 也可以用于创建操作,只要在创建前就可以确定资源的 id。
  • 永远去使用可以指向资源的的最短 URL 路径
  • RESTful 中不建议出现动词
  • 这里我选择了 PUT 而不是 POST,因为我觉得点赞这种行为应该是幂等的,多次操作的结果应该相同。
  • Token 的状态保持一般有两种方式实现:一种是在用户每次操作都会延长或重置 TOKEN 的生存时间(类似于缓存的机制),另一种是 Token 的生存时间固定不变,但是同时返回一个刷新用的 Token,当 Token 过期时可以将其刷新而不是重新登录。
  • 一般客户端会把请求参数拼接后并加密作为 Sign 传给服务端,这样即使被抓包了,对方只修改参数而无法生成对应的 Sign 也会被服务端识破。
  • 尽量使用 HTTP 状态码
  • data是真正需要返回的数据,并且只会在请求成功时才存在,msg只用在开发环境,并且只为了开发人员识别。客户端逻辑只允许识别code,并且不允许直接将msg的内容展示给用户。
  • JSON 比 XML 可视化更好,也更加节约流量,所以尽量不要使用 XML。
  • 创建和修改操作成功后,需要返回该资源的全部信息。
  • 即使客户端一个页面需要展示多个资源,也不要在一个接口中全部返回,而是让客户端分别请求多个接口。
  • 推荐使用游标分页
張 旭

从《凤凰项目》谈一谈"业务IT一体化" - 知乎 - 0 views

  • IT能多大程度上参与到业务系统中去帮助到业务部门,甚至影响到业务部门,你的价值就有多大。这项工作列为紧急并且重要
  • “IT内部的项目”,有一些IT部门很热衷做这方面的项目,在我看来部分的原因是因为做这些东西相对来说是IT比较好玩或者擅长的。
  • 重要但不紧急的工作,例如认真地研究和建立devops的基础环境。
  • ...11 more annotations...
  • 但变更虽然不可避免,我个人觉得应该尽可能减少(至少做到可预测),并且将变更流程自动化。
  • 最容易被人忽视的是“计划外工作”,它偷走了我们的时间。这就等于我们经常在讲的那些紧急但不重要,或者那些不紧急也不重要的事情。
  • 约束管理( Theory Of Constrain )理论
  • 他太厉害,所以不屑于写文档;他太重要,所以可以随心所欲地改东西而不走流程;他太忙,所以很多事情都要排队等他的时间来做。
  • 需要布伦特这样的人才,只是说布伦特成为了团队的约束点,怎么利用好他成为工作成败的关键(建立一些好的机制,确保他们能够更好地工作,而不是在一些低价值的内容上),而怎么帮助他提高到一个新的水平(或者培养更多的布伦特)才是长治久安的方法。
  • “业务IT一体化”与传统的模式有一个根本的区别,就是大量地使用了自动化的技术,减少中间环节。
  • IT部门内部开发、测试、运维、安全等环节的信任
  • 第一步,从产品构想、设计、开发、测试、运维到客户,这个正向的工作流,一定要理顺
  • 第二步,从客户往回推,如何建立一个健康和高效的反馈流。这里我总结为快速试错和迭代
  • 第三步,我觉得是讲到点子上了—— 业务IT一体化当然是好啊,但流程再合理,工具再强大,领导再重视,如果没有一个所有员工都认同的企业文化来做支撑,都将流于形式。没有信任来谈创新,终究是扯淡。
  • 各部门只关注自己的小目标,以自己干了多少事为荣,而不管这些事到底对于整个公司的目标实现意味着什么。
張 旭

跳出运维,才能做好运维(凤凰项目)书评 - 0 views

  • 1. 业务项目:这些通常是公司业务部门,比如产品研发部门或销售部门所提出的需求,比如新产品发布上线、为客户做实施、双十一这种大促活动的规划等等。这些工作通常具有一定的系统性,需要部门间通力合作。2. 内部项目:运维部门内部围绕业务项目所实施的一些列基础设施研发,部署自动化、多环境构建、持续交付、监控报警等等。3. 变更:根据其它部门申请,对运维组件进行变更操作,相对于业务项目,变更通常都会比较零散,比如加权限、开端口、开机器等等。对于变更,我们要维护好操作记录,做到有迹可寻。4. 计划外的工作:无法预料的问题处理,即“救火”。
  • 计划外的工作越多,就会占用其它三种工作的时间,导致其它三种工作大量积累。
  • 运维内部的基础建设跟不上,无法从根上去思考和解决计划外的工作,就会造成一种恶性循环,做不完的工作越堆越多(书中喜欢叫这玩意儿"半成品")直至让人崩溃。
  • ...4 more annotations...
  • 一些周期性的工作对于运维其实也是非常重要的,比如对组件进行周期性的巡检、压测、像ChaosMonkey那样对分布式系统进行随机破坏、灾难演习、备份演习等等。不过这些也可以归结在内部项目之中
  • 流水线可视化了后,除了解决掉瓶颈节点,其它的诸如任务优先级、任务的依赖关系、每批次解决的任务数量,也都会显示出来并得到解决。
  • 反馈和朔源。我们需要知道每种任务流水线的每个环节的执行情况,效率、质量,然后与该环节相关的部门一起去探讨和优化改进的措施,比如部署时间过长,那么就要与开发团队一起优化打包流程和部署所依赖的中间件架构;线上故障太多,那么就需要联合开发和QA部门一道,去审视这些故障所爆发的源头,定制解决方案,等等
  • 第三步,就需要建立一种文化机制,努力把这种工作方式延续下去,做到持续改进,越来越好!
張 旭

SSL/TLS协议运行机制的概述 - 阮一峰的网络日志 - 0 views

  • 客户端先向服务器端索要公钥,然后用公钥加密信息,服务器收到密文后,用自己的私钥解密。
  • 互联网加密通信协议的历史,几乎与互联网一样长。
  • 将公钥放在数字证书中。只要证书是可信的,公钥就是可信的。
  • ...20 more annotations...
  • 每一次对话(session),客户端和服务器端都生成一个"对话密钥"(session key),用它来加密信息。
  • "对话密钥"是对称加密,所以运算速度非常快
  • 服务器公钥只用于加密"对话密钥"本身,这样就减少了加密运算的消耗时间。
  • "对话密钥"
  • "握手阶段"(handshake)
  • 客户端向服务器端索要并验证公钥
  • "握手阶段"的所有通信都是明文的
  • 客户端发送的信息之中不包括服务器的域名。也就是说,理论上服务器只能包含一个网站,否则会分不清应该向客户端提供哪一个网站的数字证书。这就是为什么通常一台服务器只能有一张数字证书的原因。
  • 2006年,TLS协议加入了一个Server Name Indication扩展,允许客户端向服务器提供它所请求的域名。
  • "客户端证书"。比如,金融机构往往只允许认证客户连入自己的网络,就会向正式客户提供USB密钥,里面就包含了一张客户端证书。
  • 验证服务器证书。如果证书不是可信机构颁布、或者证书中的域名与实际域名不一致、或者证书已经过期,就会向访问者显示一个警告,由其选择是否还要继续通信。
  • 从证书中取出服务器的公钥
  • 随后的信息都将用双方商定的加密方法和密钥发送
  • 前面发送的所有内容的hash值,用来供服务器校验。
  • 随机数用服务器公钥加密
  • 整个握手阶段出现的第三个随机数,又称"pre-master key"。有了它以后,客户端和服务器就同时有了三个随机数,接着双方就用事先商定的加密方法,各自生成本次会话所用的同一把"会话密钥"。
  • 不管是客户端还是服务器,都需要随机数,这样生成的密钥才不会每次都一样。由于SSL协议中证书是静态的,因此十分有必要引入一种随机因素来保证协商出来的密钥的随机性。
  • 一个伪随机可能完全不随机,可是是三个伪随机就十分接近随机了,每增加一个自由度,随机性增加的可不是一。
  • 服务器收到客户端的第三个随机数pre-master key之后,计算生成本次会话所用的"会话密钥"。
  • 客户端与服务器进入加密通信,就完全是使用普通的HTTP协议,只不过用"会话密钥"加密内容。
  •  
    "客户端先向服务器端索要公钥,然后用公钥加密信息,服务器收到密文后,用自己的私钥解密。"
1 - 8 of 8
Showing 20 items per page