CLI中使用ss代理

  • 安装

sudo pacman -S privoxy
  • 软件配置

sudo vim /etc/privoxy/config
  • 填入
    forward-socks5 / localhost:1080 . 以及 listen-address 127.0.0.1:8118

其中为 ss 所在 pc 的 ip 以及 ss 的端口,后一个是本地的 http 接口

  • 重启服务

systemctl restart privoxy
  • 系统配置,让Terminal里的http访问走8118端口

export http_proxy='http://localhost:8118'
export https_proxy='http://localhost:8118'
  • 测试:

curl http://www.google.com
  • 关闭代理

unset http_proxy
unset https_proxy

常见的VPS虚拟化架构

现在主流的vps虚拟架构主要是OpenVZ、XEN、KVM,很多朋友会很困惑,比如说为什么OpenVZ架构的vps(如搬瓦工)无法安装锐速,无法进行shadowsocks的参数优化等,而kVM或者XEN类型的vps可以完成以上任务,本文就来简单的介绍下这几种vps常见的虚拟化架构。

1 OpenVZ

OpenVZ(简称OVZ)采用SWsoft的Virutozzo虚拟化服务器软件产品的内核,是基于Linux平台的操作系统级服务器虚拟化架构。本质上来讲,OpenVZ并不是虚拟机,它是一种容器,因此内核是与宿主机共享的,涉及到修改内核的操作都会权限不足。

1.1 优点:

1、性能高,容器只损失1%-2%的性能
2、伸缩性最好,不重启就可以改变磁盘空间,RAM大小和CPU核心数
3、共享内核带来的优势:启动快,系统占用RAM非常小,几乎忽略不计了
4、旧版本OpenVZ的突发内存,还有新版的vSwap(其实vSwap就是突发内存,并不是存在于硬盘上的)在需求大的时候可以救急。
5、价格较低,低价中也不乏优质的。





阅读剩余部分 -

容器改变世界 之 容器风靡全球的背后(直播 PPT 下载)

Q&A汇总:

Q1:容器会取代虚机吗?

A1:其实我们认为在可以预见的中短期内,Docker 与虚拟机应该是共存的状态。虚拟机是资源的载体,而应用是在资源之上,这中间的生态层面其实是不一样的。通过观察现在已有的IT架构和公有云平台也可以发现,几乎没有大规模的公有云放弃虚拟化而使用容器做资源分配。

虚拟化出来的资源相当于裸机,而使用容器可以获得大规模调动的能力,这两者其实形成了共存、互补的生态体系。Docker 技术的出现其实就是更好的解决传统解决方案的不足之处。

Q2:传统的 CT 应用和新兴的IT应用是否都能实现容器化?在引进容器化的过程中会面临什么挑战?

A2:都可以容器化,容器就像集装箱,集装箱的好处在于标准化,使用容器化会带来改变,但是最终会提高效率,让应用开发运维更加高效和标准化。

Q3:能提供 oracle 服务么?

A3:DaoCloud 公有云没提供,DaoCloud 企业级会进行相关集成。

Q4:服务发现可以有专题科普么?

A4:微服务专题有一篇,服务发现的可行方案以及实践案例 http://blog.daocloud.io/microservices-4/

Q5:容器的镜像好做么?相关厂商多么?

A5:现在 Docker 有自己个官方镜像市场 Docker Hub,而 DaoCloud 也提供自己的镜像市场 DaoCloud Hub,也有不少私有的镜像市场。DaoCloud 镜像仓库是我们对所有用户开放的公有镜像仓库,我们精选了数十款镜像,并翻译和修改了镜像的概览介绍信息。

Q6:请问,Docker 对于微服务架构有什么帮助?

A6:在服务打包和部署方面,有很多种不同的实现方案,包括:虚拟机(VM),还有 Docker 容器等。而 Docker 容器更是拥有其得天独厚的优势。Docker 容器其实在很多方面比虚拟机更为便捷,一方面它是自包含的,同时也提供很好的隔离和管理便捷性。另外,和虚拟机不同的是,容器更加轻量级。它们尤其构建快速,创建简便,还有运行秒级。另外,Docker 容器同样是一个移植性非常棒的打包模式。

Q7:对于传统的服务 Docker 可有好的融合的切入点?

A7:微服务 和 Devops。

Q8:请问 docker data volume 存储怎么选择选型,尤其要考虑数据可伸缩型?

A8:关于存储卷,如果需要对存储卷进行进一步管理,可以考虑使用 Docker 存储卷的插件进行更复杂的配置。

DaoCloud 企业版通过 Rexray 与 ScaleIO 集成,可以配置存储卷的容量、性能限制等。可以根据需求选择合适的存储方案然后整合到 Docker 的存储卷就可以了。

Q9:目前 Docker 在安全方面还有哪些坑?

A9:这个可以参考我们总结的的一篇博文:史上最全 Docker 安全问题回顾http://blog.daocloud.io/a-look-back-at-one-year-of-docker-security/

Q10: Docker 重启后都归零,应用的数据和端口是否可以保存和固定?

A10:可以,数据可以通过存储卷映射本地路径到容器内进行持久化,运行容器的时候可以使用-v, –volume=[host-src:]container-dest[:<options>]来配置存储卷。

端口也可以通过参数的方式固定,如果是运行容器,使用-p参数,docker run -d -p 90:8000 格式如 hostPort:containerPort ,也可以使用 Compose 编排的端口配置方法。只是固定本地端口的做法会让容器在本地无法扩展成多个。

Q11:请问 Docker 内置的编排系统和现在以后编排系统的对比?

A11:最近的 DockerCon 也提到 Docker 容器的集群管理,分布式应用在容器集群上的编排管理,一直是 Docker 想为用户解决的最大痛点之一。之前 DockerCompose 编排也经过了两个版本,未来 Swarmkit 的 Compose 会有新的变化,不过编排的内容其实是没有变得,这个还需要等待 Docker 和 Swarmkit 稳定。

Q12:Docker 跑应用会造成性能损失吗?

A12:Docker 相比虚拟化性能损失更小,更为原生,而且 Swarm 在大量应用运行的时候,各种负载条件下都拥有明显的性能优势。

Q13:请问 Docker 在存储方面要怎么做?

A13: Docker 存储可以分为两部分,首先普通的存储卷管理也就是本地卷,这些数据是与主机绑定,需要开发者自己管理,另外就是通过一些存储的插件来完成,通过不同的存储驱动在存储软件或者服务上创建你的存储卷,比如 Rexray 插件可以支持 EMC 、亚马逊等一些存储方案。

Q14:对 Docker 开发者有什么建议?

A14:我们接触到的用户有两大类,一类想法比较超前,会使用 Goang、Ruby、Python 这些前卫的编程语言,以及 SaaS 服务的用户;他们使用 Docker 是为了写一些新应用、新 App,能够以微服务化或者 cloud native application 化的方式来使用 Docker 。

另一类则是传统用户,他们已经有着一些不错的企业应用,在考虑如何搬进 Docker 。比如企业用户有很好的Java应用,他们希望利用 Docker 在效率提升、云平台管理等方面的优点。对于这类用户,我会建议他们明确哪些应用搬进 Docker 后是效果提升的、而哪些是适得其反,我会协助他们进行分析。

通常情况下,Docker 是在软件开发中协助你设置完全一致化的环境,使得开发环境、测试环境和运行环境具有一致性。对于这些旧应用,如果需要频繁开发、更新,那么放入 Docker 中就会带来实际的好处。有些几年都不更新的,放在 Docker 和放在虚拟机里区别不大。这时候我们要做清楚的区分。

Q15:Docker 发展很快,但国内的镜像下载很慢,怎么克服这种速度瓶颈?

A15:您可以使用 DaoCloud 加速器,我们已经有两个版本,第一版,结合国内的 CDN 服务,为用户提升镜像下载的速度,解决了国内用户访问 Docker Hub 缓慢的问题;第二版,加入了 DaoCloud 大量自主研发的协议层优化,并提供了可以替代 docker pull 的客户端,完美解决国内获取 Docker 镜像 metadata 的问题,并再次成倍提升下载速度。

Q16:后期会将 Docker 整体的架构吗?更新的太快,教程太杂了。

A16:首先,Docker 的基本架构和思想还是比较明确而稳定的,在容器管理这个层面的变化不大,镜像的构建和使用基本稳定,现在发展迅速的是更高层次的应用的编排等偏应用的层面。另外,各类技术都在通过新的设计让用户能更方便的使用,从而提高开发、运维等过程的效率,只要关注 DaoCloud 的公众号就可以获取最新最全的 Docker 相关的信息,so easy 。

Q17: image 镜像过大怎么办?微服务后应用特别小,但是镜像的操作系统和中间件相对特别大!

A17:首先镜像过大的原因要搞清楚,是应用还是里面的系统,根据具体情况作精简。另外 Docker 在镜像复用方面设计得非常出色,大大节省镜像占用的磁盘空间,比如两个景象的基础镜像都是 ubuntu:14.04,那么镜像存储的时候其实只需要一份系统镜像层。推荐一篇「Allen 谈 Docker 系列」之深刻理解 Docker 镜像大小。

Q18:能不能简单介绍一下是如果要在企业里把微服务在 Docker 上跑起来,需要做哪些事?架构是怎样的?

A18:从微服务的角度,对于企业组织而言,从传统模式(单体应用,瀑布式开发等)到现代化模式(微服务,敏捷式开发,DevOps 等)是一个主要的变化。从企业角度,很多主机的 Docker 管理需要一个 DaoCloud企业版这类管理平台,在这个平台之上可以快速高效的进行容器构建、运维。

我们内部就非常强调架构微服务和交付实际化的研发理念,团队采取的是小步快跑、持续迭代的方式。关于微服务和 Docker,推荐可以参考月初 Chris 关于微服务的深刻探讨,DaoCloud 官网还有相关的专题http://blog.daocloud.io/chris-interview/

Q19:你好,有什么好的方式从现有架构过渡到容器方式呢?

A19:现在我们比较推荐使用微服务架构进行快速迭代,微服务架构可以优化简化开发流程,应用微服务化以后,每个开发者会负责一个对应的模块,这样开发者会有新的动力去做不断改进他们所负责的模块。

Q20:容器跨主机的网络管理用的什么技术?

A20: Docker 原生的 Overlay 网络是比较常用的一种,DaoCloud 企业版就是使用 Overlay 网络作为跨主机的虚拟网络,并支持网络与容器之间连接等操作。

Q21:能直接提供数据库服务吗?

A21:在 DaoCloud 公有云中我们已经提供了直接的 Mysql,Mongo,PostgreSql 等多个数据库服务,DaoCloud 企业版已经提供了对应的数据库应用模版。未来还会支持更加方便的数据库的集成方案。

Q22: hadoop on docker 这个可有做?计算集群能用 Docker 搭建不?

A22:当然都是可以的做的,在 DaoCloud 企业级 DCE 中应用市场已经添加了 hadoop 相关的应用编排模版、以及 Spark 的应用模版,未来还会继续丰富我们企业级的应用市场。

下载PPT

点击链接:http://pan.baidu.com/s/1qYgVRn2


来源

如何挑选适合的前端框架

最近几年,前端技术迅猛发展,差不多每年都会冒出一款主流的框架。 每次新开业务线或启动新项目时,是第一件事就是纠结:使用什么框架,重造什么轮子?我很高兴应CSDN的邀请谈我的看法。

在五六年,移动端还没有兴起,我们没有什么选择,就是jQuery。有人会说,jQuery只是类库,不是框架;但那时前端业务还没有像今天这么繁重,原本是后端干的事,全部挪到前端来,因为光是jQuery就可以包打天下。jQuery不够用,还有成千上万的jQuery的插件呢。于是问题就是这样一一衍生出来了,一个页面太多jQuery插件了,请求数太多了,于是我们得打包。打包需要我们对插件有规划。于是这需求在社区上逐渐形成了某些规则,其中最出名的是AMD规范,体现上requirejs这个加载库上。

requirejs是前端技术发展上的一个分水岭。javascript在es6之前一直没有自己的加载机制,requirejs的出现意味着前端可以向更大规模发展。以后我说的技术选型,一个非常重要的甄选点, 就是 是否存在加载器机制或符合某个模块规范。

requirejs

回到原来的话题,选择框架要从两面看,一是看该框架的本领,二是看你们团队的能耐。

从框架的角度来看, 它的功能丰富不丰富,社区活跃度如何,国内社区活跃度如何(有的在国外流行,但国内只有初创公司或一些大公司的边缘项目在试水),文档齐全吗,及时更新吗,测试覆盖率如何,上手难度如何,都是我们考量点。不过能进我们视野内的外国框架,基本是身经百战,在造轮子兴盛的世界闯出来的领头羊。jQuery, angular, knockout, emberjs, polymer, react, backbone, zepto,我们基本是围绕在这几个上面转了。当然还有更大型的东西, EXT, YUI, dojo, easyui, bootstrap, 这是UI库层面的。

下面是2012年外国对当时流行12个javascript MVC框架的纯技术评估:
12个javascript MVC框架的纯技术评估
显然,我们第一步就是圈定时下最流行的框架与库,作为评估对象,然后再根据自家公司的情况进行筛选。贵公司是建站公司,还是有自己产品的公司呢?如果是建站公司,页面不会复杂到哪里去,基本上jQuery+bootstrap 搞定,不要想得太多,就是它们。如果有自己产品, 要维护一大堆客户数据要与客户打交道,不难想象是存在非常复杂的CRM系统,按照中国人的特性,这东西只会越来越复杂,这就要慎重考虑了。这往往是持续十年的维护升级,我们需要看一下这框架是否有你们的产品那么长寿,这框架的升级更新是否频繁平缓。

如果你的项目是一个跨度三年以上的大工程,用《人月神话》的术语来说,90%就是个焦油坑。我们需要使用更稳键成熟的技术方案,我们需要重点避开谷歌的产品,它的许多产品都是玩票性质, GWT、Closure、Darty就是前车之鉴。polymer是基于许多新技术构建(http://www.csdn.net/article/2013-05-27/2815450-google-polymer),其中Object。observe(), Custom Elements, HTML Imports,Shadow DOM, Model-Driven Views是远远没被标准化, 许多还是独家的, 变数太大,因此才出现如下的悲剧 http://weibo.com/1712131295/CfB7X336J?type=comment#_rnd1430880258836。 angular不是我黑它, 这东西也喜欢断崖式升级, 它在1.08时兼容IE6-8, 1.2时需要打补丁兼容旧式IE, 1.3摒弃对旧式IE的兼容,直接在源码中删除所有兼容代码,因此所有补丁方案都无力回天,并且不支持全局Ctrl函数,许多模块需要独立引用,1.4不向下支持动画模块, 2.0由at改成ts构建,由于使用Object.observe,因此不支持IE6-11,chrome30-……

请输入图片描述

如果你们的产品是后台系统,那么就有两个选择,使用EXT, easyui这些重大的UI库方案,其中EXT具有严重的排它性,它很难与其他前端解决方案并用。什么模块组织,打包,数据可视化,它都已经全部帮你搞定。它文档齐备漂亮, 入门难度中等, 但它要求你的团队非常稳定,现在招一个专职EXT的前端是很难的。easyui是国内比较大牌的UI框架,虽然闭源,不过想扩展它不是难事。此外,国内的淘宝kissy, 网易nej也不错。还有更轻量的方案,MVVM。MVVM最擅长做这些重交互的产品。举例说,为了对应复杂交互的gird,jquery社区开发出各种庞大巨物 datagrid, jqgrid, flexigrid,还不如MVVM几个循环绑定来个干脆利落,扩展性又好。目前,knockout, emberjs, angular与我写的avalon就是这一类框架。angular虽然有点坑,但如果你是从1.3用起,并且不鸟IE,它还是一个不错的选择,其活跃的社区为它带来无限的可能。knockout在。net人群中非常流行,微软出品,前端MVVM框架的鼻祖,不过它需要对后端数据进行过多的加工,因为它本身是不支持对套嵌对象的绑定。emberjs没有一个好干爹,但有一个好亲爹,作者Yehuda Katz是jQuery, rails, Sproutecore, Merb, Handlebars这些著名框架的核心成员, 虎父无犬子,emberjs现在还是国外的第二大MVVM框架。avalon是比较适合国情的MVVM,有它专门兼容IE6的版本,易上手,性能高,视频教程多,出了问题可以抓得着作者,是它的几大卖点。

如果你们的产品是商场这样重演示类的产品,就对SEO有要求,MVVM就不适合了。目前也就angular与avalon在搞后端渲染机制,但还不上了台面。这时jQuery+bootstrap+requirejs就非常好用。requirejs的作用不单单是提供了一个按需加载机制,它还能让我们组织起更为庞大的代码。如果不用requirejs,国内另一个选择是seajs,它的规范是CMD。此外还有commonjs规范, 但这无法直接运行于前端,需要借助fekit, fis, webpack这样的构建工具进行合并了。不管怎么说,你这时选用的框架必须存在AMD,CMD或commonjs任一种加载规范,这方便你以后的横向扩展。至于插件,目前小插件们都趋向用UMD( https://github.com/umdjs/umd ),它可以让AMD,CMD,commonjs任一种加载器加载。

如果你们的产品是移动端,基本上是SPA架构了,因为这会减少等待,整页刷新与请求数。目前该领域非常混乱了,不同于PC端,这要兼容的浏览器是多出N倍,并且为了性能,浏览器商乱砍功能或改变一些浏览器特性的行为,这往往引发一些奇怪的BUG,目前社区正在整理这些坑与解药( https://github.com/jtyjty99999/mobileTech )。但目前没有一个框架能够摆平所有问题,都需要多管齐下。我的见解是

requirejs(按需加载,移动端上可以不打包,善用304缓存,腾讯搞出一个更牛叉的增量更新加载器MT,也可以试试) + backbone(组织代码与路由管理) + zepto(轻量DOM操作) + fastclick.js(点击穿透与延迟处理) + hammer.js(各种触屏事件) + iscroll5.js(滚动条处理) + Animate.css(CSS3动画) + Enquire.js(处理响应式布局)。

可见移动端每个部件都烂到蕊了,每个部件都需要专门的工具进行修复。移动端是非常注重体验的,每一个小角落都存在着各种动画,但浏览器或自带的webview都很差劲,于是native与hybird的话题才一直这么火。有的人说,既然dom是最吃性能,那么就干脆用canvas来代替吧( http://zhuanlan.zhihu.com/FrontendMagazine/19967854http://www.ruanyifeng.com/blog/2015/02/future-of-dom.html )。facebook也推出自己类似的方案, react native,自己实现一套GUI,不过编写语言是javascript。它是使用自己原来的超高性能轮子react实现的。这或者是一条道路。但优缺点也明显,正如angular浓浓的java风,react是在逻辑插入大段标签语言(jsx)。同时react的排它性也非常强,很难与其他库搭配使用。同时,我们可以看到,出自jQuery名门的jQuery mobile并没有入围,那个性能太糟了,连sencha touch。上面说的只是核心库, 还没有搬出UI库呢。号称mobile first的UI库不在少数,由于无视IE,可以大胆使用CSS3。目前比较出彩的有,foundation,semantic,refill, ratchet。如果只是想运行在平板上,性能问题就不会那么拮据了,我们还可以试试inoic, sencha touch, Kendo UI Mobile……

基本上,针对每个平台,我都列出一些主流框架了,但不意味着你们都能驾驭得住。小马过马,老牛没过膝,松鼠淹个半死,就是这么回事。创业公司喜欢新框架,这与他们拿得起高薪招一两个前端牛人而致,基本上所有页面就是他们干的,因此用angular或ember都没区别。小公司则小心,人员流失大,jQuery+requirejs是万金油。大公司则基本上有自己的技术沉淀,换言之,应该有自己的前端框架,除非那东西很陈旧,不建议再造轮子。大公司建议是搞自己的技术委员会,根据自己的人员配置来挑选的框架。有句话说得好,不求最好,但求最合适.有些框架就属于牛逼人手里牛逼闪闪,二逼人手里一团乱麻的。对于某些成长特别快的中等公司来说,这点最需防范 ,牛人是有的,但作战的主体70%都是刚培训出来的实习生,难上手,中文文档不全的框架就必须过滤掉。我也不排除造轮子的可能性,毕竟有些公司就是人才济济,能推出一些靠谱的开源产品来造福社区。

但无论我们选择什么框架或决定自己动手造轮子,都勿忘初心,技术必须让我们工作生活更为轻松愉快——我们只选择我们能驾驭住的框架,我们不能保证它在一年后会过时落后,但至少不会变成绊脚石。套用亚当·斯密的话(税收是一种必要的恶)来说,框架是一种必要的恶,它是强约束的,因此必须慎重选择。


来源

最新文章

最近回复

分类

  • 默认分类 (24)
  • 运维 (53)
  • docker (1)
  • 动漫 (19)
  • 科普知识 (15)
  • 苍白边缘 (12)
  • 资源 (12)
  • Linux (59)
  • Arch Linux (20)
  • 计算机 (18)
  • 编程 (4)
  • Java (5)
  • python (0)
  • php (0)
  • 前端 (1)
  • 归档




      其它