用户您好!请先登录!

Archives八月 2019

Istio 基础知识

一、Istio概念

使用云平台可以为组织提供丰富的好处。然而,不可否认的是,采用云可能会给 DevOps 团队带来压力。开发人员必须使用微服务以满足应用的可移植性,同时运营商管理了极其庞大的混合和多云部署。Istio 允许您连接、保护、控制和观测服务。

在较高的层次上,Istio 有助于降低这些部署的复杂性,并减轻开发团队的压力。它是一个完全开源的服务网格,可以透明地分层到现有的分布式应用程序上。它也是一个平台,包括允许它集成到任何日志记录平台、遥测或策略系统的 API。Istio 的多样化功能集使您能够成功高效地运行分布式微服务架构,并提供保护、连接和监控微服务的统一方法。

什么是服务网格?

在从单体应用程序向分布式微服务架构的转型过程中,开发人员和运维人员面临诸多挑战,使用 Istio 可以解决这些问题。

服务网格(Service Mesh)这个术语通常用于描述构成这些应用程序的微服务网络以及应用之间的交互。随着规模和复杂性的增长,服务网格越来越难以理解和管理。它的需求包括服务发现、负载均衡、故障恢复、指标收集和监控以及通常更加复杂的运维需求,例如 A/B 测试、金丝雀发布、限流、访问控制和端到端认证等。

Istio 提供了一个完整的解决方案,通过为整个服务网格提供行为洞察和操作控制来满足微服务应用程序的多样化需求。

阅读更多

Service Mesh基础知识

1. 介绍

Service Mesh 概念

Service Mesh又译作“服务网格”,作为服务间通信的基础设施层。Willian Morgan(Linkerd的CEO)如下定义Service Mesh。

A service mesh is a dedicated infrastructure layer for handling service-to-service communication. It’s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application. In practice, the service mesh is typically implemented as an array of lightweight network proxies that are deployed alongside application code, without the application needing to be aware. (But there are variations to this idea, as we’ll see.)

Service Mesh 是一个基础设施层,用于处理服务间通信。云原生应用有着复杂的服务拓扑,Service Mesh 保证请求可以在这些拓扑中可靠地穿梭。在实际应用当中,Service Mesh 通常是由一系列轻量级的网络代理组成的,它们与应用程序部署在一起,但应用程序不需要知道它们的存在。

Service Mesh 实际上就是处于 TCP/IP 之上的一个抽象层,它假设底层的 L3/L4 网络能够点对点地传输字节(当然,它也假设网络环境是不可靠的,所以 Service Mesh 必须具备处理网络故障的能力)。

Service mesh 有如下几个特点:

  1. 应用程序间通讯的中间层;
  2. 轻量级网络代理;
  3. 应用程序无感知;
  4. 解耦应用程序的重试、超时、监控、追踪和服务发现;

2. 原理

Service Mesh 基本原理

如果用一句话来解释什么是 Service Mesh,可以将它比作是应用程序或者说微服务间的 TCP/IP,负责服务之间的网络调用、限流、熔断和监控。对于编写应用程序来说一般无须关心 TCP/IP 这一层(比如通过 HTTP 协议的 RESTful 应用),同样使用 Service Mesh 也就无须关系服务之间的那些原来是通过应用程序或者其他框架实现的事情,比如 Spring Cloud、OSS,现在只要交给 Service Mesh 就可以了。

Phil Calçado 在他的这篇博客 Pattern: Service Mesh 中详细解释了 Service Mesh 的来龙去脉:

  1. 从最原始的主机之间直接使用网线相连
  2. 网络层的出现
  3. 集成到应用程序内部的控制流
  4. 分解到应用程序外部的控制流
  5. 应用程序的中集成服务发现和断路器
  6. 出现了专门用于服务发现和断路器的软件包/库,Twitter’s Finagle和 Facebook’s Proxygen。这时候还是集成在应用程序内部
  7. 出现了专门用于服务发现和断路器的开源软件,如:NetflixOSS ecosystem
  8. 最后作为微服务的中间层Service Mesh出现

Service Mesh 的架构如下图所示

3. 方案

目前社区Service Mesh的开源解决方案有:Buoyant 公司推出的 Linkerd 和 Google、IBM 等厂商牵头的 Istio。Linkerd 更加成熟稳定些,Istio 功能更加丰富、设计上更为强大,社区相对也更加强大一些。所以普遍认为 Istio 的前景会更好,但是毕竟还处于项目的早期,问题还很多。

3.1 Istio 介绍

Istio是由Google、IBM和Lyft开源的微服务管理、保护和监控框架。Istio为希腊语,意思是”起航“。官方中文文档地址:https://istio.doczh.cn

Istio架构图

istio-arch

Istio架构分为控制层和数据层。

  1. 数据层:由一组智能代理(Envoy)作为sidecar部署,协调和控制所有microservices之间的网络通信。
  2. 控制层:负责管理和配置代理路由流量,以及在运行时执行的政策。

Istio架构各个组成部分。

  • Envoy:Istio使用Envoy代理的扩展版本,该代理是以C++开发的高性能代理,用于调解service mesh中所有服务的所有入站和出站流量。
  • Mixer:Mixer负责在service mesh上执行访问控制和使用策略,并收集Envoy代理和其他服务的遥测数据。
  • Istio Manager:Istio-Manager用作用户和Istio之间的接口,收集和验证配置,并将其传播到各种Istio组件。
  • Istio-auth:Istio-Auth提供强大的服务间和最终用户认证,使用相互TLS,内置身份和凭据管理。

3.2 Linkerd 介绍

Linkerd 是开源网络代理,设计为以服务网格部署:用于管理,控制和监控应用程序内的服务与服务间通讯的专用层。

Linkerd 架构图

 

Linkerd 基本功能 原文链接

  1. Load balancing:负载均衡算法,它们使用实时性能指标来分配负载并减少整个应用程序的尾部延迟。
  2. Circuit breaking:自动熔断,将停止将流量发送到被认为不健康的实例,从而使他们有机会恢复并避免连锁反应故障。
  3. Service discovery:服务发现后端集成,通过删除特定的(ad-hoc)服务发现实现来帮助您降低代码的复杂性。
  4. Dynamic request routing:动态请求路由和重新路由,允许您使用最少量的配置来设置分段服务(staging service),金丝雀(canaries),蓝绿部署(blue-green deploy),跨DC故障切换和黑暗流量(dark traffic)。
  5. Retries and deadlines:在某些故障时自动重试请求,并且可以在指定的时间段之后让请求超时。
  6. TLS:可以配置为使用 TLS 发送和接收请求,您可以使用它来加密跨主机边界的通信,而不用修改现有的应用程序代码。
  7. HTTP proxy integration:可以作为 HTTP 代理,几乎所有现代 HTTP 客户端都广泛支持,使其易于集成到现有应用程序中。
  8. Transparent Proxying:在主机上使用 iptables 规则,设置通过 linkerd 的透明代理
  9. gRPC: 支持 HTTP/2 和 TLS,允许它路由 gRPC 请求,支持高级 RPC 机制,如双向流,流程控制和结构化数据负载。
  10. Distributed tracing:分布式跟踪和度量仪器,可以提供跨越所有服务的统一的可观察性。
  11. Instrumentation:支持分布式跟踪和度量仪器,可以提供跨越所有服务的统一的可观察性。

4. 扩展阅读

5. 参考资料

 

Nginx应用部署那点事

什么是 Nginx?

Nginx (engine x) 是一款轻量级的 Web 服务器 、反向代理服务器及电子邮件(IMAP/POP3)代理服务器。

Nginx 极简教程(快速入门)

什么是反向代理?

反向代理(Reverse Proxy)方式是指以代理服务器来接受 internet 上的连接请求,然后将请求转发给内部网络上的服务器,并将从服务器上得到的结果返回给 internet 上请求连接的客户端,此时代理服务器对外就表现为一个反向代理服务器。

Nginx 极简教程(快速入门)

阅读更多

伯克利论断:Serverless 才是云时代的主宰

来自伯克利的犀利断言:Serverless 计算将会成为云时代默认的计算范式,将会取代 Serverful (传统云)计算模式,因此也意味着服务器 – 客户端模式的终结。

你准备好了吗?

引言

2009 年,伯克利以独特的视角发布了一篇文献,定义了云计算,十年过去了,这篇文章被引用无数,其中的观点更是当下最好的见证:

  1. 按需计算的表现形式。
  2. 消除云用户的前期承诺。
  3. 根据需要在短期内支付使用计算资源的能力。
  4. 规模经济,由于许多非常大的数据中心,显着降低了成本。
  5. 通过资源虚拟化简化操作并提高利用率。
  6. 通过多路复用来承载不同组织的工作负载,进而提高硬件利用率。

2019 年,伯克利又以新的视角发布了一篇文献:将云中的编程变得简单:伯克利视角下的 Serverless 计算。 观点同样让人眼前一亮:

阅读更多

微软关于微服务体系结构的理解

微服务体系结构由一系列小型的自治服务组成。 每个服务都是自包含服务,并且应实现单个业务功能。

微软关于微服务体系结构的理解

在某些方面,微服务是面向服务的体系结构 (SOA) 的自然演变,但微服务与 SOA 之间也存在一些差异。 下面是微服务的一些典型特征:

  • 在微服务体系结构中,服务具有规模小、独立和松散耦合的特点。
  • 每个服务都是一个单独的基本代码,可由小型开发团队管理。
  • 服务可独立部署。 团队可以更新现有服务,而无需重新生成和重新部署整个应用程序。
  • 服务负责暂留自己的数据或外部状态。 这一点与传统模型不同,后者由单独的数据层处理数据暂留。
  • 服务通过定义完善的 API 相互通信。 每个服务的内部实现细节均对其他服务隐藏。
  • 服务无需共享相同的技术堆栈、库或框架。

除了服务本身,典型微服务体系结构中还会出现其他组件:

阅读更多

分布式系统中的唯一id生成策略及实现

系统唯一ID是我们在设计一个系统的时候常常会遇见的问题,也常常为这个问题而纠结。生成ID的方法有很多,适应不同的场景、需求以及性能要求。所以有些比较复杂的系统会有多个ID生成的策略。

简单分析一下需求

所谓全局唯一的 id 其实往往对应是生成唯一记录标识的业务需求

这个 id 常常是数据库的主键,数据库上会建立聚集索引(cluster index),即在物理存储上以这个字段排序。这个记录标识上的查询,往往又有分页或者排序的业务需求。所以往往要有一个time字段,并且在time字段上建立普通索引(non-cluster index)。普通索引存储的是实际记录的指针,其访问效率会比聚集索引慢,如果记录标识在生成时能够基本按照时间有序,则可以省去这个time字段的索引查询。

这就引出了记录标识生成的两大核心需求:

  • 全局唯一
  • 趋势有序

阅读更多

图数据库 Nebula Graph简介

Nebula Graph:一个开源的分布式图数据库。作为唯一能够存储万亿个带属性的节点和边的在线图数据库,Nebula Graph 不仅能够在高并发场景下满足毫秒级的低时延查询要求,还能够实现服务高可用且保障数据安全性。

简介

Nebula Graph 是开源的第三代分布式图数据库,不仅能够存储万亿个带属性的节点和边,而且还能在高并发场景下满足毫秒级的低时延查询要求。不同于 Gremlin 和 Cypher,Nebula 提供了一种 SQL-LIKE 的查询语言 nGQL,通过三种组合方式(管道、分号和变量)完成对图的 CRUD 的操作。在存储层 Nebula Graph 目前支持 RocksDB 和 HBase 两种方式。

Nebula Graph 整体架构

图数据库 Nebula Graph 的安装部署

阅读更多

金融类应用App的用户体系搭建

用户体系只是单纯的积分/会员/等级么?如何从零开始梳理我的APP的用户体系?金融类产品的用户体系有什么特殊性?一个优秀的用户体系可以为我的APP带来什么?

全文思维导图如下:

万字长文|从零搭建互联网金融APP的用户体系(01)

01 “用户体系”从何而来?

当你的APP积累了一定的用户数量,老板说:“小刘啊,我看咱们APP也有几万用户了,最近都没啥增长了,你要不搞个用户体系激励一下?”

阅读更多

链路追踪那点事

在微服务横行的时代,服务化思维逐渐成为了程序员的基本思维模式,但是,由于绝大部分项目只是一味地增加服务,并没有对其妥善管理,当接口出现问题时,很难从错综复杂的服务调用网络中找到问题根源,从而错失了止损的黄金时机。

而链路追踪的出现正是为了解决这种问题,它可以在复杂的服务调用中定位问题,还可以在新人加入后台团队之后,让其清楚地知道自己所负责的服务在哪一环。

除此之外,如果某个接口突然耗时增加,也不必再逐个服务查询耗时情况,我们可以直观地分析出服务的性能瓶颈,方便在流量激增的情况下精准合理地扩容。

链路追踪

“链路追踪”一词是在2010年提出的,当时谷歌发布了一篇Dapper论文,介绍了谷歌自研的分布式链路追踪的实现原理,还介绍了他们是怎么低成本实现对应用透明的。

阅读更多

杭州除了新旧十景还有很多打卡的地方

断断续续在杭州生活了一两年,因为喜欢那里的关系,以前也没有少去,除了大家都周知的新旧十景,杭州还有很多值得一去的地方。

浙江大学·之江校区

100张图,向你安利杭州100处最佳打卡地(上)

杭州最美校园,浙大之江校区坐落于杭州西湖区钱塘江畔,作为中国的十三所基督教大学之一,校园内的建筑都很有美国风情,尤其是红瓦的钟楼。

地址:浙江省杭州市西湖区之江路51号

阅读更多

架构之美:Less is More

计算机领域的架构师一词正是来源于建筑领域的房屋、桥梁等建筑的架构设计。这个古老的工种,经历了各种各样的风格,从中国古代的飞檐斗栱,到中世纪欧洲的歌德,拜占庭式建筑,从东正教的园顶到到巴黎的宫殿。建筑演变到今天,人们越来越多的崇尚简单。

看看大师们的建筑杰作,应该在计算机领域又何尝不是一样。“Less is More”(少即是多)是设计界广为流传的一句名言。提出它的是20世纪最伟大的建筑师之一密斯·凡得罗,简单主张已变成一种不断演化的想像和一种持续的精神活动。延续至今,甚至延伸为品位的哲理。

Less ismore,建筑的极简之美

阅读更多

物联网的架构初探

物联网概念

物联网(Internet of Things,缩写IoT),是在计算机互联网的基础上,通过射频识别(Radio Frequency Identification,RFID)、红外感应器、全球定位系统、激光扫描器等信息传感设备,按约定的协议,把任何物品与互联网连接起来,进行信息交换和通讯,以实现智能化识别、定位、跟踪、监控和管理的一种网络。

物联网主要解决物品到物品(Thing to Thing,T2T),人到物品(Human to Thing,H2T),人到人(Human to Human,H2H)之间的互连。

听着有点术语化,可以从一个简单的故事说起。

阅读更多

敏捷开发那点事

第一次接触敏捷是2000年初在摩托罗拉的项目中,想起那时候的结对编程,到现在回想起来仍然觉对对自己的帮助很大。后来陆陆续续经历过各种开发管理过程,究其本质,大都相似。

一、极限编程

极限编程(ExtremeProgramming,简称XP)是由KentBeck在1996年提出的。极限编程是一个轻量级的、灵巧的软件开发方法;同时它也是一个非常严谨和周密的方法。XP是一种近螺旋式的开发方法,它将复杂的开发过程分解为一个个相对比较简单的小周期;通过积极的交流、反馈以及其它一系列的方法,开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等,并根据实际情况及时地调整开发过程。

1.1、XP的核心价

XP的核心价值观是沟通(Communication)、简单(Simplicity)、反馈(Feedback)、勇气(Courage)、谦逊(Modesty)。 XP用“沟通、简单、反馈、勇气和谦逊”来减轻开发压力和包袱;无论是术语命名、专著叙述内容和方式、过程要求,都可以从中感受到轻松愉快和主动奋发的态度和气氛。这是一种帮助理解和更容易激发人的潜力的手段。XP用自己的实践,在一定范围内成功地打破了软件工程“必须重量”才能成功的传统观念。

阅读更多

使用IO重定向来对付 rm -rf

前言

每当我们在生产环境服务器上执行rm命令时,总是提心吊胆的,因为一不小心执行了误删,然后就要准备跑路了,毕竟人不是机器,更何况机器也有bug,呵呵。

那么如果真的删除了不该删除的文件,比如数据库、日志或执行文件,该怎么解决?

模拟场景

1. 删除

误删除服务器目录/root/selenium/Spider下的MySql.Data.dll文件:

> rm -f /root/selenium/Spider/MySql.Data.dll
> ll /root/selenium/Spider/MySql.Data.dll
ls: cannot access /root/selenium/Spider/MySql.Data.dll: No such file or directory

阅读更多

老美的未来20年科技发展趋势

美国公布了一份长达35页的《新兴科技趋势报告》。该报告是在美国过去五年内由政府机构、咨询机构、智囊团、科研机构等发表的32份科技趋势相关研究调查报告的基础上提炼形成的。

通过对近700项科技趋势的综合比对分析,最终明确了20项最值得关注的科技发展趋势。

该报告的发布:

一是为了帮助美国相关部门对未来30年可能影响国家力量的核心科技有一个总体上的把握。二是为国家及社会资本指明科技投资方向,以确保美国在未来世界中的战略优势。

一、物联网

2045年,最保守的预测也认为将会有超过1千亿的设备连接在互联网上。

这些设备包括了移动设备、可穿戴设备、家用电器、医疗设备、工业探测器、监控摄像头、汽车,以及服装等。它们所创造并分享的数据将会给我们的工作和生活带来一场新的信息革命。

阅读更多

ZooKeeper:分布式协调服务原理

ZooKeeper是一种用于分布式应用程序的分布式开源协调服务。它公开了一组简单的原语,分布式应用程序可以构建这些原语,以实现更高级别的服务,以实现同步,配置维护以及组和命名。它被设计为易于编程,并使用在熟悉的文件系统目录树结构之后设计的数据模型。它在Java中运行,并且具有Java和C的绑定。

众所周知,协调服务很难做到。他们特别容易出现竞争条件和死锁等错误。ZooKeeper背后的动机是减轻分布式应用程序从头开始实施协调服务的责任。

设计目标

ZooKeeper很简单。ZooKeeper允许分布式进程通过共享的分层命名空间相互协调,该命名空间的组织方式与标准文件系统类似。名称空间由数据寄存器组成 – 在ZooKeeper用语中称为znodes – 这些与文件和目录类似。与专为存储而设计的典型文件系统不同,ZooKeeper数据保存在内存中,这意味着ZooKeeper可以实现高吞吐量和低延迟数量。

阅读更多

幂等性设计那点事

前言

小伙伴们有没有遇到过生产环境经常出现过重复的数据?在排查问题的时候,数据又是正常的。这个是何解呢?怎么会出现这种情况,而且还很难排查问题。要知道重复数据的出现在电商和支付领域是很可怕的事情。

罪魁祸首

产生重复数据或数据不一致(假定程序业务代码没问题),绝大部分就是发生了重复的请求重复请求是指同一个请求因为某些原因被多次提交。导致这个情况会有几种场景

1)微服务场景,在我们传统应用架构中调用接口,要么成功,要么失败。但是在微服务架构下,会有第三个情况【未知】,也就是超时。如果超时了,微服务框架会进行重试。

2)用户交互的时候多次点击。如:快速点击按钮多次。

3)MQ消息中间件,消息重复消费

4)第三方平台的接口(如:支付成功回调接口),因为异常也会导致多次异步回调

5)其他中间件/应用服务根据自身的特性,也有可能进行重试。

我们知道了发生的原因,本质就是多次请求了,那如何解决呢?

阅读更多

下一个10年,未来在哪里?

2019年开启的下一个科技十年,会是个选择题么?

  • A:人工智能
  • B:区块链
  • C:云(计算)
  • D:大数据

从互联网时代到移动互联网时代到现在的5G时代,甚至接下来的6G时代,数据传输的速率将达到我们难以想象的地步,通信与交互的方式有可能彻底改变我们的生活。

我们所经历的Web1.0, 2.0, 3.0等往往利用着人性的贪婪在牟利。在接下来真正的万物互联时代,企业与市场的竞争希望会向人性的善意转向。

人工智能能够解放重复性劳动,给予用户独立思考的机会么?

区块链将不可更改的记录下每个人作恶或者向善的痕迹,甚至企业与国家行为。

云计算(云服务)会开启更低成本的个人与企业创新机会么?

大数据能使黄赌毒的违法成本大幅度上升,从而促进一个信用社会的建立么?

打个问号,立据求证。

Code Review那点事

在一家公司的技术部门或者在一家技术公司中,Code Review和测试一样,估计是最不受待见的东西了,大家都认为它很重要,可就是不愿意或者做不好。资深的瞧不上资历潜的,潜意识中息的代码是最好的思维总在作祟。

于我观察到的大部分软件开发团队来说,认真做Code Review的很少,有的流于形式,有的可能根本就没有Code Review的环节,代码质量只依赖于事后的测试。也有些团队想做好代码审查,但不知道怎么做比较好。

Code Review有什么好处?

很多团队或个人不做Code Review,根源还是不觉得这是一件有意义的事情,不觉得有什么好处。这个问题要从几个角度来看。

团队知识共享

一个开发团队中,水平有高有低,每个人侧重的领域也有不同。怎么让高水平的帮助新人成长?怎么让大家都对自己侧重领域之外的知识保持了解?怎么能有人离职后其他人能快速接手?这些都是团队管理者关心的问题。

阅读更多

卷积神经网络CNN那点事

在讨论卷积神经网络(CNN)之前,我们来回顾一下什么是神经网络。我们可以搭建全联接类型的神经网络(full connection neural network),然后使用反向传播(Back Propagation – BP)和梯度下降训练神经网络。这种BP网络可以很好的处理较小的图片。

一文搞懂卷积神经网络(Convolutional Neural Networks-CNN)

但是BP网络在处理较大的图片时会遇到下列棘手的问题:

•图片需要预处理(旋转、去燥、灰度化等),有时还要手工抽取特征

•网络权值太多,训练需要很多样本,计算困难

•网络泛化能力较弱

阅读更多


1 2 3 4 5 6 7