Browsed by
标签:Google

https://daniel.haxx.se/about.html

https://daniel.haxx.se/about.html

閱讀本文約花費: 21 (分鐘)This is the story of my background. What I’ve done and how I ended up like this. Daniel Stenberg I was born and raised in Huddinge, a suburb south of Sweden’s capital Stockholm. I have two brothers and two sisters. 1985 – it begins I discovered the joy of computers for the first time sometime in the early 80s when Kjell, a friend of mine, and I entered data sets in Basic that we eagerly read in some of the first C64 magazines at his place and since then I’ve been hooked. Kjell owned a C64 before me so it was in his home I had my first experiences in the …

Read More Read More

Clair助力Docker镜像安全

Clair助力Docker镜像安全

閱讀本文約花費: 5 (分鐘)Clair 是 CoreOS 最近发布的一款开源容器漏洞扫描工具。该工具可以交叉检查Docker 镜像的操作系统以及上面安装的任何包是否与任何已知不安全的包版本相匹配。漏洞是从特定操作系统的通用漏洞披露( CVE )数据库获取。该工具当前支持的操作系统包括 Red Hat 、 Ubuntu 和 Debian 。 通过从镜像文件系统中抽取静态信息以及维护一个组成镜像的不同层之间的差异列表,可以大大减少分析时间,而且不需要实际运行可能存在漏洞的容器。如果镜像所依赖的一个靠下的层存在漏洞,那么该镜像就会被识别为有漏洞,而且,通过使用图存储,可以避免重新分析镜像。 CoreOS使用Clair 分析用户上传到 Quay.io (一个类似 DockerHub 的容器注册中心)的 Docker 镜像。现已发现, Quay 上的大多数镜像都存在漏洞,甚至是像 Heartbleed(80%)或 Ghost(67%)这样的著名漏洞。2015 年初,一份有关 DockerHub 的报告推断,至少有30% 的官方镜像和多达40% 的用户上传镜像包含高级漏洞。期间,在 DockerCon 2015 欧洲大会上,…

Read More Read More

Kubernetes 社区是如何运作的系列之二——康威定律和SIG

Kubernetes 社区是如何运作的系列之二——康威定律和SIG

閱讀本文約花費: 10 (分鐘)生产关系能否决定生产力?为什么这个社会需要管理?Kubernetes 是如此的成功,它的开源治理和技术架构是有着非常密切的关系的。 Tue Feb 6, 2018 | 3000 Words | 大约需要阅读 6 分钟 | | 康威定律(Conway’s Law) 随着信息技术的发展,以及现实的IT公司的成功,如Amazon、Netflix,以及云计算的普及,微服务的实践正在走向很多传统用户,然而,实施微服务的过程中,和DevOps的理念一样,人们发现并非仅仅是技术所能够解决的。还要涉及到组织架构。于是,伴随着微服务的发展,一位很少被人提及的科学家被推到了前端,也是被人忽视而尘封的科学家。 时间要拨回到1967年,Melvin Conway 以独特的视角观察到一个组织的组织结构会对其开发的系统有很大的影响。并撰写了“How Do Committees Invent” 这样一篇影响深远的论文,其中被人们广为知道的结论: 设计系统【这里也不仅仅是指信息系统】的组织,其产生的设计和架构等价于组织间的沟通结构。 该定律基于这样一个推理:为了能够让软件之间的模块相互作用,软件的撰写者们必须相互频繁的进行沟通,因此,系统的软件界面结构将会反映出打造此系统的组织的社会边界,要知道跨边界的沟通是比较困难的。Conway 定律的目的是试图说明这是蛮常见的社会学…

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

Service Mesh实践之Istio初体验

Service Mesh实践之Istio初体验

閱讀本文約花費: 16 (分鐘)微服务国内发展背景: 2014年,Martin Fowler撰写的《Microservices》使得许多国内的先行者接触到微服务这个概念并将其引入国内,2015年越来越多的人通过各种渠道了解到微服务的概念并有人开始在生产环境中落地,2016-2017年,微服务的概念被越来越多的人认可,带动了一大批公司以微服务和容器为核心开始技术架构的全面革新。 至今微服务已经历了两代发展,第一代以Spring Cloud为代表的微服务开发框架,该框架在微服务发展的前几年一度独领风骚,甚至在部分人群中成为微服务的代名词,但事实上该微服务框架并不是唯一实现微服务的方式;第二代微服务技术为服务网格(Service Mesh),它的出现解决了大部分开发人员在使用Spring Cloud中遇到的不足和痛点。 Service Mesh是如何解决这些问题的,又是何以赢得众多开发者的支持呢?笔者就这些问题给大家分享一篇以Istio为代表的第二代微服务实践。 一、微服务和Istio Service Mesh基本概念 服务网格是一个基础设施层,主要用于处理服务间的通信。云原生应用有着复杂的服务拓扑,服务网格负责在这些拓扑中实现请求的可靠传递。在实践中,服务网格通常实现为一组轻量级网络代理,它们与应用程序部署在一起,而对应用程序透明。 图1展示了服务网格的拓扑,当微服务数量增多达到几十上…

Read More Read More

Kubernetes集群搭建:基于Kubeadm

Kubernetes集群搭建:基于Kubeadm

閱讀本文約花費: 16 (分鐘)一,环境准备 * K8S版本为15.1 * Docker版本最高支持18.06.1 二,Docker环境构建及替换 1,清除原Docker环境,原版本为最新版 yum remove docker \docker-client \docker-client-latest \docker-common \docker-latest \docker-latest-logrotate \docker-logrotate \docker-selinux \docker-engine-selinux \docker-engine rm -rf /etc/systemd/system/docker.service.d rm -rf /var/lib/docker rm -rf /var/run/docker 2,如果清除后依旧包冲突错误 file /usr/share/man/man1/docker-manifest-annotate.1.gz from install of docker-ce-18.06.1.ce-3.el7.x86_64 conflicts with file from package docker-ce-cli-1:18.09.6-3.el7.x86_64 通过yum命令手动移除冲突包 yum erase docker-common-2:1…

Read More Read More

使用Istio治理微服务入门

使用Istio治理微服务入门

閱讀本文約花費: 20 (分鐘)近两年微服务架构流行,主流互联网厂商内部都已经微服务化,初创企业虽然技术积淀不行,但也通过各种开源工具拥抱微服务。再加上容器技术赋能,Kubernetes又添了一把火,微服务架构已然成为当前软件架构设计的首选。 但微服务化易弄,服务治理难搞! 一、微服务的“痛点” 微服务化没有统一标准,多数是进行业务领域垂直切分,业务按一定的粒度划分职责,并形成清晰、职责单一的服务接口,这样每一块规划为一个微服务。微服务之间的通信方案相对成熟,开源领域选择较多的有RPC或RESTful API方案,比如:gRPC、Apache Thrift等。这些方案多偏重于数据如何打包、传输与解包,对服务治理的内容涉及甚少。 微服务治理是头疼的事,也是微服务架构中的痛点。治理这个词有多元含义,很难下达一个精确定义,这里可以像小学二年级学生那样列出治理的诸多近义词:管理、控制、规则、掌控、监督、支配、规定、统治等。对于微服务而言,治理体现在以下诸多方面: 服务注册与发现 身份验证与授权 服务的伸缩控制 反向代理与负载均衡 路由控制 流量切换 日志管理 性能度量、监控与调优 分布式跟踪 过载保护 服务降级 服务部署与版本升级策略支持 错误处理 …… 从微服务治理角度来说,微服务其实是一个“大系统”,要想将这个大系统全部落地,绝非易事,尤其是之前尚没有一种特别优雅的技术方案。多数方案(…

Read More Read More

6种微服务RPC框架,你知道几个?

6种微服务RPC框架,你知道几个?

閱讀本文約花費: 7 (分鐘)跟语言平台绑定的开源 RPC 框架主要有下面几种。 Dubbo:国内最早开源的 RPC 框架,由阿里巴巴公司开发并于 2011 年末对外开源,仅支持 Java 语言。 Motan:微博内部使用的 RPC 框架,于 2016 年对外开源,仅支持 Java 语言。 Tars:腾讯内部使用的 RPC 框架,于 2017 年对外开源,仅支持 C++ 语言。 Spring Cloud:国外 Pivotal 公司 2014 年对外开源的 RPC 框架,仅支持 Java 语言 而跨语言平台的开源 RPC 框架主要有以下几种。 gRPC:Google 于 2015 年对外开源的跨语言 RPC 框架,支持多种语言。 Thrift:最初是由 Facebook 开发的内部系统跨语言的 RPC 框架,2007 年贡献给了 Apache 基金,成为 Apache 开源项目之一,支持多种语言。 如果你的业务场景仅仅局限于一种语言的话,可以选择跟语言绑定的 RPC 框架中的一种; 如果涉及多个语言平台之间的相互调用,就应该选择跨语言平台的 RPC 框架。 RPC 框架,它们具体有何区别? 1. Dubbo 先来聊聊 Dubbo,Dubbo 可以说是国内开源最早的 RPC 框架了,目前只支持 Java 语言,它的架构可以用下面这张图展示。 从图中你能看到,Dubbo 的架构主要包含四…

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

云原生架构概述

云原生架构概述

閱讀本文約花費: 9 (分鐘)1. 什么是云原生 1.1 CNCF组织 在讲云原生之前,我们先了解一下CNCF,即云原生计算基金会,2015年由谷歌牵头成立,基金会成员目前已有一百多企业与机构,包括亚马逊、微软。思科等巨头。 目前CNCF所托管的应用已达14个,下图为其公布的Cloud Native Landscape,给出了云原生生态的参考体系。 1.2 云原生 CNCF给出了云原生应用的三大特征: 容器化封装:以容器为基础,提高整体开发水平,形成代码和组件重用,简化云原生应用程序的维护。在容器中运行应用程序和进程,并作为应用程序部署的独立单元,实现高水平资源隔离。 动态管理:通过集中式的编排调度系统来动态的管理和调度。 面向微服务:明确服务间的依赖,互相解耦。 云原生包含了一组应用的模式,用于帮助企业快速,持续,可靠,规模化地交付业务软件。云原生由微服务架构,DevOps 和以容器为代表的敏捷基础架构组成。 这边引用网上关于云原生所需要的能力和特征总结,如下图。 云原生所需要的能力和特征 1.3 The Twelve Factors 12-Factors经常被直译为12要素,也被称为12原则,12原则由公有云PaaS的先驱Heroku于2012年提出,目的是告诉开发者如何利用云平台提供的便利来开发更具可靠性和扩展性、更加易于维护的云原生应用。具体如下: 基准代码 显式声明依赖关…

Read More Read More

蚂蚁金服 Service Mesh 实践探索

蚂蚁金服 Service Mesh 实践探索

閱讀本文約花費: 50 (分鐘)摘要 在勇敢的选择了Service Mesh作为未来技术方向之后,蚂蚁金服率先开始了Service Mesh大规模落地探索。在此过程中,我们遇到很多问题,面临各种挑战,也有了一些思路和方法。今天我们将这些实践分享出来,并结合我们开源的SOFAMesh项目,和大家一起探讨:如何更好的将Service Mesh这样的新兴技术落地于实际生产环境。 大家好,我是来自蚂蚁金服中间件团队的敖小剑,目前是蚂蚁金服 Service Mesh 项目的PD。我同时也是 Servicemesher中国技术社区 的创始人,是 Service Mesh 技术在国内最早的布道师。我今天给大家带来的主题是”长路漫漫踏歌而行:蚂蚁金服Service Mesh实践探索”。 今天我们的内容不是继续做 Service Mesh 的布道,今年要好好讲一讲实践。所以今天我不会像去年那样给大家详细解释 Service Mesh 是什么,能做什么,有什么优势。而是结合过去一年中蚂蚁金服的实践经验,结合蚂蚁金服的 SOFAMesh 产品,帮助大家更深刻的理解 Service Mesh 技术。 在开始今天的内容分享之前,我们先来热个身,温习一下去年的内容。去年我是来布道的,而布道的核心内容就是告诉大家:Service Mesh 是什么? 为了帮忙大家回答,我给出一个提示图片,了解 Service M…

Read More Read More

Service Mesh (服务网格) 入门

Service Mesh (服务网格) 入门

閱讀本文約花費: 11 (分鐘)现在最火的后端架构无疑是微服务了,微服务将之前的单体应用拆分成了许多独立的服务应用,每个微服务都是独立的。 微服务基本组件包括服务注册和发现、服务通信和治理、故障熔断恢复、配置、安全、监控等等,这些微服务组件和功能在业界已经深入人心,在各大互联网公司开花结果,业界知名开源的微服务框架有 Netflix OSS、Spring Cloud 及其国内的阿里 Dubbo 等等,各种框架百花齐放。 微服务好处自然很多,但是随着应用的越来越大,微服务暴露出来的问题也就随之而来了,微服务越来越多,管理越来越麻烦。特别是要你部署一套新环境的时候,随之而来的服务发现、负载均衡、Trace跟踪、流量管理、安全认证等等问题。 当然随着微服务的不断发展,微服务的生态的不断完善,新的微服务框架 Service Mesh 的出现就是为了解决这一系列问题。 什么是 Service Mesh Service Mesh 是一个非常新的名词,最早是 2016 年由开发 Linkerd 的 Buoyant 公司提出的,伴随着 Linkerd 的传入,Service Mesh 的概念也慢慢进入国内技术社区。 Service Mesh 是一个基础设施层,其独立运行在应用服务之外,提供应用服务之间安全、可靠、高效的通信,并为服务通信实现了微服务运行所需的基本组件功能,包括服务注册发现、负载均…

Read More Read More

Docker不香吗,为啥还要K8s?

Docker不香吗,为啥还要K8s?

閱讀本文約花費: 16 (分鐘)上一篇文章我们着重讲解了 Docker,其实遗留了一个大问题。Docker 虽好用,但面对强大的集群,成千上万的容器,突然感觉不香了。 这时候就需要我们的主角 Kubernetes 上场了,先来了解一下 K8s 的基本概念,后面再介绍实践,由浅入深步步为营。 关于 K8s 的基本概念我们将会围绕如下七点展开: Docker 的管理痛点 什么是 K8s? 云架构 & 云原生 K8s 架构原理 K8s 核心组件 K8s 的服务注册与发现 关键问题 Docker 的管理痛点 如果想要将 Docker 应用于庞大的业务实现,是存在困难的编排、管理和调度问题。 于是,我们迫切需要一套管理系统,对 Docker 及容器进行更高级更灵活的管理。 Kubernetes 应运而生!Kubernetes,名词源于希腊语,意为「舵手」或「飞行员」。 image Google 在 2014 年开源了 Kubernetes 项目,建立在 Google 在大规模运行生产工作负载方面拥有十几年的经验的基础上,结合了社区中最好的想法和实践。 K8s 是 Kubernetes 的缩写,用 8 替代了 「ubernete」,下文我们将使用简称。 什么是 K8s ? image K8s 是一个可移植的、可扩展的开源平台,用于管理容器化的工作负载和服务,可促进声明式配置和自动化。 …

Read More Read More

左耳朵耗子- 技术博客学习

左耳朵耗子- 技术博客学习

閱讀本文約花費: 3 (分鐘)1.通过在公司工作提高自己的技能,让自己可以更为独立和自由地生活。 2.对于没什么技术含量的工作内容,提高交付效率。把时间用来研究高技术含量的知识。3.要写文章就写别人没有写过的,或是别人写过,但我能写得更好的。4.看清市场需求(各个公司正在做什么,难题是什么)和技术趋势(首先要了解技术的历史,把本质吃透:看经典书籍,向前沿学习)5.在学习技术的过程一定要多问自己两个问题:“一,这个技术解决什么问题?为什么别的同类技术做不到?二,为什么是这样解决的?有没有更好的方式?”另外,还有一个简单的判断方法,如果一个新的技术顺应技术发展趋势,那么在这个新的技术出现时,后面一定会有大型的商业公司支持(专门做此类技术的公司),这类公司支持得越多,就说明你越需要关注。6.在一家高速发展的公司中,技术人员的价值可以达到最大化。比较好的成长路径是,先进入大公司学习大公司的技术和成功的经验,然后再找到高速成长的公司,这样你就可以实现自己更多的价值。7.动手能力很重要,持续在前线工作。8.关注技术付费点:一个是,能帮别人“挣钱”的地方;另一个是,能帮别人“省钱”的地方。9.提高自己的能力和经历。找到有价值的信息源(知识的源头:西方世界) ,最好的技术在西方: google (xxx_技术 best practice/programming , Best programming…

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

MEGAEASE的远程工作文化

MEGAEASE的远程工作文化

閱讀本文約花費: 27 (分鐘)MegaEase 是我创业的公司,主要是想把云计算(PaaS/SaaS层)的那些高可用高并发的分布式技术普及到那需要对技术自主可控的公司,这样就不需要去使用不能自主可控的闭源系统或是大公司的云平台。我于2016年开始成立MegaEase,从早期8个人,直到今天有20来个人,我们从一开始到今天都是在远程工作的公司文化。因为我很喜欢《Rework》这本书,写这本书的公司叫37signal(现名basecamp),这家公司在发《Rework》这本书的时候,整个公司只有16个人,分布在全世界8个城市,这种Geek的公司的文化很吸引我,所以,在我决定创业的时候,我就止不住地想成立这样能够远程工作的公司,于是,远程工作的团队文化就这样成为了MegaEase的基因。下面我会分享一下,我们公司的远程工作文化和其中的一些问题,最后还有一个工作协议。 我们在早期的时候,8个员工来自5个城市,现在的20来个员工来自8个城市2个国家。虽然我们现在使用“共享办公室”,但是本质上,我们的整个文化是远程工作的文化。在2017-2018年度,我们公司产品商业化以来,公司早期的8个工程师在远程工作的状态下成功支持了得到的老罗的跨年演讲活动,以及其它几个客户,一方面验证了用户愿意付费购买我们的产品和服务之后,另一方面也有一些不错的收入,客单价都在百万左右。还记得当时,有几个投…

Read More Read More

Scroll Up