技术行业的宏观趋势

我们每半年发布一次技术雷达:它是所有我们认为横跨业界当下和将来的相关重要技术的快照。我们从世界各地召集了约20位最有资历的技术人来编写技术雷达,这也是一个用全球视角对比趋势和方向的绝佳机会。我们在技术雷达上总结出了主要的潮流,但这其中的奥妙足以再专门写一篇长文章。在此,我们将关注于技术雷达中未能覆盖到的一些宏观趋势。

1-macro-trends

强大的团队和商业

开拓新业务所需要的不仅仅是好软件。

开源软件现在出现了大爆炸式的集中发布,其中有一些公司公开了那些你可能认为是专属或有竞争优势的软件。比如,谷歌的TensorFlow深度学习工具包Netflix的整体产品栈

乍一想这似乎是个糟糕的主意:竞争对手可能用这些代码一步登先,然后进行竞争。但Google真正的’秘密武器’不是软件,而是软件中的数据。对于Netflix,其云规模不(再)是竞争性优势,真正的优势在于他们的原始内容、有许可的交易和品牌力量。

这些都是著名的利用软件与技术促使企业变强变大的例子,但这不是企业成功的真正原因。我们看到很多赢家通过关注“产品思维”来创建优秀的体验,同时吸引和保留优秀的员工来打造他们的产品。在这种情况下,开源软件更多的被用于招聘和增加名誉,公司即便将软件免费赠送,也可以保持自己的市场领导地位。

2-team

自治团队赢得全栈控制权。

在过去的几年里,我们看到了“谁创建,谁运行”的敏捷团队的崛起:由同一批人来创建、发布软件,并为之做产品支持。我们是这种方式的拥护者,最起码做产品支持能够让人成为一个更优秀的开发者

这种趋势在逐渐扩大,我们能够看到团队的控制权越来越深入,选择PaaS,然后在此基础上部署、运行他们的(通常是基于云的)负载以及运行测试工具、监控工具和安全工具。这是一个好的趋势,但最终,企业环境中需要一些标准化。我们喜欢Spotify的方式允许团队创新,然后寻求最佳解决方案——这是一个处在创新和高效之间不错的平衡。

开源是高尚的副产品。

开源软件中的创新比以往发生得都更加迅速。之前我们提到了Google和Netflix发布开源代码库,但是如果你在搜索引擎中敲入“开源”+公司名称,你很有可能找到满满一页都在讲述该公司对于开源软件贡献页面。公司投资于开源软件有两大原因。

第一个是获取有天赋的人:随着技术越来越强力地驱动着商业和社会,能否寻找最具天赋的人才是成功的关键要素。但是作为一个技术人员,搞清楚自己是否真的想要为某个公司工作是困难的——面试过程和实际工作之间有巨大的差异。开源软件能够帮助候选人通过查看该公司产生的代码质量,来对一个组织获得更深的理解,也能帮助公司为潜在新成员展示其技术文化。第二个是将之作为文化声明。很多技术人员相信分享和重用的力量,为开源软件做贡献是一个公司展示与此哲学一致性的方式。

平台和生态系统提升生产力

开发者们主要通过代码来沟通。

讨论技术问题最好的方式通常是代码交流。敏捷宣言的原则之一是“可工作的软件”优于“理论或观点”,而开源软件就反映了这一点。

不同于试图用长篇大论解释所有技术问题的细节,开发者们通常会写一部分或全部代码,使用Github的代码社交功能来轻松讨论、接受或拒绝建议。直接通过代码来讨论,通常会带来更加高效的讨论,我们也逐渐看到这种技术在企业上下文中被采用。企业正在采用一种“内部开源”的模型,在这样模型下,源代码可以随时被分享出来并用于协作。但企业应该在面临风险时,忽略这种趋势。

3-paas

每个人都应该使用PaaS,但这个选择并不是永恒不变的。

能够参与到从“数据中心里放的一堆堆服务器”到“按需索求的虚拟基础设施”的业界革命的过程一向都是激动人心的,ThoughtWorks也一直处在譬如DevOps和持续交付等运动的领导前沿。客户常常要求我们使用云策略帮助他们,而我们今天的建议通常是“你需要采用PaaS”。

很多组织已经欣然接受了IaaS并且创造了复杂的基于“chuppet’的、领域特定的、通常由一些胶水代码和shell脚本搭起来的PaaS。尽管这些土生土长的平台已经够用了,但我们认为现有的PaaS产品更加成熟、值得一用。

PaaS可供选择的范围很大,从高度结构化的选项比如Cloud foundry和OpenShift,到无结构的以容器为中心的选项例如Mesos和Kubernets。我们不认为这些平台是万灵药。很有可能你会需要深入到IaaS底层来满足你的结果(比如配置复杂的网络)或者它们会降低你的灵活性(比如使之很难使用某个服务定位库)。但是一个PaaS,如果实现得当,能够为大多数企业级开发选购带来巨大的生产力。我们曾见证过,仅仅是利用将平台标准化、取得高效的部署、运行app,就产生了两倍生产力的爆发。和要求20个团队自己搞明白部署策略相比,PaaS是绝对的规则变革者。

Docker,Docker,Docker。

如果缺少了Docker,那整个技术行业的概述都不是完整的。这个容器化现象已经吸引了所有人的关注力,不管是开发者、测试者还是产品运营专家。Docker首先使包装一个应用或组件到容器里变得十分容易,在这基础之上,它还可以管理容器的各个生命周期。

Docker对于开发场景十分适用,比如从在同一个笔记本上运行多个微服务,到利用Docker镜像作为规模和管理单元来跨数据中心管理大型产品负载。我们认为最有趣的是围绕着Docker的高能源生态系统。现在的确有和Docker相竞争的工具,但是Docker在人们脑海中的占有率和其投资有着重要的意义,而且很有可能,在可预见的未来它会变成架构设计、开发策略和产品PaaS平台的底层基础。

Swift生态系统发展逐渐加速。

我们编写此次雷达时,讨论了很多Swift工具、库和框架,尽管它们不是每一个都光彩夺目。在诸如Microsoft的.Net, Ruby on Rails, Scala和Clojure等已沿用多年的平台基础上,开发者们在用Swift重新创造他们最中意的软件。这是Swift平台逐渐接近成熟的好兆头,而且它也是iOS开发的不错的选择。特别地,我们会质疑任何使用Objective-C为起点来开发新的项目。

4-swift

基于“计算组织体”的创新持续加速

底层技术——IoT, VR, 和Blockchain——给提供我们重要的组件块

当我们评估新的技术趋势时,观察其下支撑的工程学和物理学是非常有指导性的。比如说,物联网,就是由于底层的工程,诸如电池、高性能低功耗芯片、无处不在的网络连接的进步而变为可能的。这些智能的、相互连接的设备会带来诸多优势,首当其冲就是在那些能显著改善效用和节能的工业和商业环境下。消费者物联网依然停留在浅显的、小把戏的程度,在接下来几年里需要解决重要的安全和隐私问题。虚拟现实在譬如Oculus Rift和HTC Vive平台上的应用越来越广泛,超越游戏范畴的VR会随着我们逐步采用这个新组件块而变成一个增长领域。至于blockchain,我们预期在未来6~18个月中有比较缓慢的增长,但在超分布式信任和不可改总账之下,存在着我们可以用于建立商业、经济甚至社会的新能力。

当今时代显然是科技工作的黄金时代。在接下来的六个月里,我们期待能够看到这些趋势持续带给我们生产力上的增长,使团队和商业变得更加有力,并带给我们前所未有的全新想法和模式。我们也想要听听你的想法,在评论区告诉我们你心中最重要的行业趋势,以及未来我们可能见证要发生的事情吧!


你想看到的洞见,都在这里

wechat

Share

解读ThoughtWorks技术雷达的正确姿势

接地气的技术雷达

ThoughtWorks在每年都会出品两期技术雷达,这是一份关于技术趋势的报告,它比起一些我们能在市面上见到的其他各种技术行情和预测报告,更加具体,更具可操作性,因为它不仅涉及到新技术大趋势,比如云平台和大数据,更有细致到类库和工具的推介和评论,从而更容易落地。

这是2016年4月份的技术雷达全貌:

2016 April tech radar post

其中,自上次雷达发表以来新出现或发生显著变化的技术以三角形表示,而没有变化的技术则以圆形表示。每个象限的详细图表显示各技术发生的移动。

技术雷达对于不同层级和水平的技术从业者,有可以从不同角度和分类进行解读的可能。不管你是个人开发者,对于新工具和技术有执着的追求,寄希望于从新工具和技术那里获取改进每日工作的灵感,或者你是技术领导者需要针对自己的系统做技术选型,以及对未来技术趋势的把握,技术雷达都会是一份很好的参考。

而如何解读技术雷达就是变成一件很有意思的事情,解读方式可以帮助我们更有效地利用它。下面会介绍几种观察技术雷达的不同角度。

这里可以下载到最新版本的中文技术雷达。

手持一份技术雷达,更新技能和工具

技术雷达在四个象限(技术,工具,平台,语言和框架)中,布满了大量由ThoughtWorks技术专家们发现的,可以极大改善开发效率和品质的条目。它们大多数会分布在每个象限的试验和评估区域。

这些条目多具备创新和极客精神,可以很大程度上改善个人开发者的开发兴趣,保持对于新技术和技能的敏感度。

下面是两个例子:

Gauge是一个轻量级的跨平台测试自动化工具。技术规格由自由的Markdown语法写成,因此,测试用例可以用业务语言而不是使用通常的 ‘given-when-then’ 这种具有局限性的格式来描述。不同语言和IDE的支持以插件的形式添加到核心实现中这使得测试人员能够与团队一起使用同样的支持自动完成、重构等功能的IDE。同时,这个ThoughtWorks出品的开源工具天生就能够并行执行所有支持平台的测试。

Aurelia采用最新的Javascript:ECMAScript 2016标准开发而成,被认为是下一代JavaScript客户端开发框架。Aurelia的作者Rob Eisenberg是Durandal之父,离开Angular2.0核心团队之后全力打造了Aurelia。Aureliarelia最了不起的是它的高度模块化,包含了许多小型库,可以非常方便的进行定制化开发。Aurelia遵循约定优于配置的理念,而且其约定恰到好处,很容易进行模块的产生和使用。Aurelia有一个庞大的开发社群,它的官网还提供了非常好的入门文档。

开发者把玩并品味,将新工具和技术应用到手头的软件开发工作中,可以给日复一日、陈旧乏味的遗留系统带来新的气象,而成就感也就伴随而来。

如果对于已经处在采用(非常推荐)区域的技术条目,如果开发者仍然觉得陌生,那这也许就是自己对技术的敏感度在下降的征兆了。比如DockerReact.js

停止对不推荐技术的过度投资

开发者会觉得有一些技术和工具方兴未艾,依然趁手,但技术雷达已经将它们放入了暂缓区域(停止推荐),开始唱衰,这样的态度可以给开发者一些前瞻性的警示。

过度地投资在不被看好前景的技术上,势必会拖累开发的节奏和进度,跟不上市场的步伐,开发者需要的是拥抱更具市场前沿性的工具和技术。

比如这一期的技术雷达对于单一CI(持续集成)实例的担忧:

因为只有一个统一的配置和监控点,但是在一个组织中多个团队共享一个臃肿的CI会导致很多的问题。构建超时、配置冲突和巨型构建队列等类似问题出现得越来越频繁。这种缺陷导致的单点失败会造成多个团队工作的中断。要认真考虑在这些陷阱和保持单点配置之间找到一个平衡点。而雷达的建议是,由各个团队分布式地管理自己独立的CI。

还有一个很显著的例子是关于雷达对于Gitflow暂缓的态度,而这里有一篇很好的文章:Gitflow有害论,来自我的同事刘尚奇。

看技术演进动态

除了可以静态地看一份最新的技术雷达,我们如果对照比较浏览最近几期技术雷达中一些技术点的动态演进趋势,这会是一个更加有趣的体验。一方面也可以培养开发者自身对位技术未来趋势的把控力,另外一方面也可以印证技术雷达的前瞻性和可靠性,

这样动态形式看技术雷达,大致可以分下面两类方式:

单看某个技术点的演进

一个典型例子可以是技术雷达关于AngularJS的态度:

虽然我们使用AngularJS成功交付了很多项目,并且也能看到大型企业中越来越多的项目采用该框架,但是我们决定在这个版本的技术雷达将Angular移回“评估”。这个改动是为了让大家注意:React.jsEmber也有很不错的可选性,Angular从1.0到2.0的迁移过程充满不确定,同时我们发现一些组织在使用这个框架时并没有认真思考单页应用是否适合他们的需要。为此我们进行了激烈的内部辩论,但是可以肯定的是,同时使用双向绑定与不一致状态管理模式会让代码变得过于复杂。另外我们相信,相比于尝试移除一个固有框架,更好的方式是通过仔细的设计,在外层使用Redux或者Flux,来解决这些问题。

目前在前端框架方面,技术雷达的新宠是React.js

另外更加明显的在技术雷达上不断演进的例子是GradleSpringBoot。比如下面是技术雷达的历次版本对于SpringBoot的推介态度:

springboot-radar

从技术雷达的主题展开看

技术雷达开头的”最新动态“旨在展现当期雷达中最为引人注目并值得关注的几个技术或者主题。比如下面是最新这一期技术雷达的主题截图:

theme-radar

由主题内容开始,去寻找当期技术雷达中对于该主题的展开论述,在各个象限内找到对其有支持和补充的具体技术点,可以在开发者脑中绘制出一份更加完整的关于这个主题的现状和趋势来。

比如对于微服务这个技术,我们可以看到在技术雷达中,有这样一些技术、工具或者平台对于微服务架构的支撑:

microservices-map

而跳出单份技术雷达,开发者可以留意到,连续两三期的技术雷达都可能在针对同一技术,做主题性质的连续阐述,来阐释这一技术点在雷达中的重要性和演进的程度。

再比如微服务,它在技术雷达中的演进过程是,2012年3月雷达建议开始评估微服务,2012年10月则建议可以在系统中试验微服务架构,直到2015年1月出现Microservice Envy(微服务羡慕嫉妒恨),雷达建议暂缓实施微服务。

可以看见,对于微服务,雷达的态度是推荐而且敏感的。跟随雷达,开发者可以提前时间预见到自己可能遭遇的坑,以及会有相应的解决方案。

同样,不止于微服务,我们仍然可以找到类似这样的主题技术在雷达中的位置和全貌。

比如技术雷达对于安全领域的关注,在最新一期中,除了积极推荐采用的威胁建模方法外,雷达还提到了一下这些技术点,从证书管理、安全规范、漏洞检查、机密信息访问等方面,提供了一些推荐试验或评估的条目:

如数家珍,开始做技术选型

现在开发一个典型的Web应用,前端+后端可以有很多技术的选择,前端AngularJS方兴未艾,ReactJS已经异军突起,而对后端进行架构和选型,可以挑选的空间则更大,我们不得不在业务和技术采纳,甚至加上遗留系统之间,做更多的权衡和把握。

比如如果我们需要尝试微服务架构,并且碰巧身处Spring生态,那么SpringBoot会是更优的选择:

很多的工作已经通过使用SpringBoot来降低复杂度和依赖, 这在很大程度上缓解了我们以前的保留意见。如果你在Spring的生态系统中并正在走向微服务架构,SpringBoot就是当下最好的选择。而那些不在Sping生态环境中项目,Dropwizard也值得认真考虑 。

我的同事佟达对关于如何采用Python作为大数据全栈式开发语言的论述,同样精彩。他就云基础设施、DevOps、网络爬虫、数据处理四个方面,细数Python技术栈的选择,对于打造一个大数据处理平台的可能,信手拈来。

就像只要会JavaScript就可以写出完整的Web应用,只要会Python,就可以实现一个完整的大数据处理平台。

期待更多

ThoughtWorks技术雷达是一份不限行业,技术中立的前瞻性技术报告。它预测技术趋势,小到一个工具和类库,大到平台和架构,而我们已经在不断见证事实的发生。本文提供了一些可能有帮助的观察技术雷达的视角,你还有更有帮助的视角吗?

Share

Kubernetes救援 – 教你如何从新技术的坑里爬出来(上)

当下新技术层出不穷,为了降低开发者的学习成本,很多新技术都会提供“Quick Start”,初学者只需要非常简单的几步,就可以把这个新技术用起来。“Quick Start”的初衷是好的,隐藏复杂性,让用户第一时间体验产品。但是,正因为复杂性被隐藏了,很多初学者在跟着“Quick Start”成功操作一遍后,会产生“我已经会了”的假象。而在引入到具体项目后,遇到问题,束手无策,只能求助于StackOverflow一知半解的答案,或者陷入到茫茫多的官方文档之中。

为什么我的眼里常含泪水?因为这坑真是又深又沉。每当被坑,我的心里就会浮现出这张图:

 

how-to-draw-a-horse

最近摆弄Kubernetes,不免又被摆了一道。

一不小心掉进坑里

作为一个发布不过两三年的新技术,Kubernetes的文档可谓做的不错。对于如何创建试用集群,Kubernetes提供了非常丰富的说明,包括基于三大云平台(AWS,GCE,Azure),Mesos集群,CoreOS集群,vagrant虚拟机,以及裸机等等。一开始,我选择vagrant多机部署,一切都是自动化的,等了大概半个多小时,显示配置成功,然后按照文档说的,执行了几个kubectl命令,看起来挺简单的。

“Quick Start”基本上都是提供一个傻瓜式命令,想变魔术一样,“嘭”,什么都有了。 因为vagrant集群是基于fedora的,而且用SaltStack做部署,每次启动都要重新下载一大堆东西,慢的要死,不适合快速创建演示环境。所以我决定稍微改变一下,用vagrant创建几个Ubuntu的虚拟机,用基于Ubuntu的多机部署方案来做演示集群。

用vagrant创建Ubuntu集群环境,done; 配置一下几台虚拟机之间的ssh key,done; 参照文档,运行几条命令,done; 这次就快多了,运行kubectl命令,没问题。一切都那么美好,我感到自己已经掌握了Kubernetes了,要不怎么说我是DevOps专家呢!看到文档里说,安装kube-ui可以看到图形界面,只需要运行./deployAddons.sh就够了。敲完命令,不断用kubectl get pods –namespace=kube-system看到对应的pod状态,变成running表示已经启动成功。我迫不及待的就去浏览器里看结果,结果就是这样:

fail-to-visit-kube-ui

看到这,我就傻眼了,说好的美图呢?不得不说,此时我的内心是崩溃的。

急救

当然,作为DevOps专家,内心的崩溃是不能让外人看出来的。所以我淡定的开始修复工作:

复制网页上的报错信息; 打开Google(是的,你没看错,是Google); 按下回车 不愧是Google,瞬间就返回了结果,有几个遇到的错误信息和我一样,但是要么是没解决,要么是重启就解决了,等于没说。恩,干得漂亮。

清点处境

既然知道没有人能帮我,我也就放心了。基于我的经历,我发现了一个定律:

Quick Start如果出了问题,是没有Quick Fix的。 深吸一口气,现在只能靠自己了。首先,清点一下我的处境。

我自己配置了三台Ubuntu虚拟机; 根据官方文档里的配置,把config-default.sh中的目标IP修改成真实的虚拟机IP,然后运行kube-up.sh,然后根据按照文档,安装了kube-ui; 网页上报错信息是:Kubernetes healthz sidecar container。 既然只有三条线索,就一个一个排查好了。首先,检查vagrant虚拟机是不是出错了:

三台虚拟机互相ping可以通,宿主机分别ping三台机器也可以通,看来虚拟机网络没问题; 通过网页控制台信息可以看到,没有任何错误,说明8080端口是工作的,而且响应正常; 用service –status-all命令列出所有服务,所有看起来跟Kubernetes有关的服务状态都是running,说明服务都运行良好。 因此暂时可以排除是基础设施的问题,再来看第二个线索,看看是不是漏掉了文档中的关键配置。于是我对着文档,一字一句的看,文档写的比较简洁,因为大部分工作都自动化了,需要配置的也不多,逐字逐句的对比也没发现什么问题。不过倒是在文档里找到一节之前没注意到文字:

kubernetes-ubuntu-doc-troubleshooting

照文档的说法,出问题,看etcd,大喜,赶紧打开日志查看。不出所料,没什么异常。不过根据这个提示,找到了Kubernetes日志输出路径和配置信息路径,也算不小的收获。按照原计划,进行第三步问题排查,看看这条出错信息能帮我找到什么。先Google下kubernetes healthz,发现在Kubernetes 201里提到,这是用来做节点健康检查的。再细想一下,本来应该显示kube-ui的页面,结果却显示了健康检查相关的内容,这说明了什么呢?暂时还不太清楚,但是这个疑问先记下。好了,再清点一下第一轮排查的收获:

找到了Kubernetes的日志,在/var/log/upstart/下面; 找到了Kubernetes的配置,在/etc/default/下面; 找到一个疑点:本该显示kube-ui的页面,却显示了健康检查相关的内容。 缩小排查范围

看起来问题还是没什么头绪,但至少又给自己找了些事情可做。在/var/log/upstart/下面,有很多日志,我可以一个一个看下去。除此之外,别无他法。有时候,没有选择也是一种幸福。先列一下都有哪些日志要查:

master minion1 minion2 docker ✓ ✓ ✓ etcd ✓ – – flanneld ✓ ✓ ✓ kubelet ✓ ✓ ✓ kube-proxy ✓ ✓ ✓ kube-apiserver ✓ – – kube-controller-manager ✓ – – kube-proxy ✓ ✓ ✓ kube-scheduler ✓ – – kube-apiserver ✓ – – 用iterm做分屏非常容易,于是把所有的log都用tail -f /var/log/upstart/.log命令打印出来:

kubernetes-log

看起来不错!当然这只是其中一个节点,另外两个没有展示。现在,我只要再次访问那个让我抓狂的页面,然后从这些漂亮的黑底白字中,找出任何蛛丝马迹,就可以直捣黄龙,解救我于水火之中了。

休息一下

总结一下目前的进展:

Kubernetes集群看似跑起来了,但是却并不能正常工作,比如kube-ui就打不开; 通过排查,基础设施的问题已经排除,将注意力集中在查找Kubernetes配置是否有问题; 监控所有日志,期待出现解决问题的线索。

休息一下,欲知后事,且听下回分解。

Share

技术雷达 : 关于技术趋势的分析报告

就在刚刚过去的2015年11月份,ThoughtWorks又发布了最新一版的技术雷达。技术雷达是什么,来源以及如何运用,可以参考Neal Ford的一篇文章《Build Your Own Technology Radar》中文翻译】,这里就不再赘述。在本期的技术雷达中,提出了四个最新的技术动态,分别为:“Docker引爆容器生态系统”、“微服务及相关工具受到追捧”、“JavaScript工具正在趋于平稳”、“安全是每一个人的问题”。本文就主要围绕这四个最新的技术动态,阐述一下笔者个人的理解和分析。

Docker引爆容器生态系统

Docker现在非常火,作为一个开源的应用容器引擎,它的出现让容器技术的使用和管理变得非常简单,也促使更多的人开始关注和意识到容器技术的真正价值和威力。由于其基于LXC的轻量级虚拟化技术,相比于KVM之类传统的虚拟机技术最明显的特点就是启动快,资源利用率高。启动一个容器只需要几秒钟,在一台普通的PC上甚至可以启动成百上千的容器,这都是传统虚拟机技术很难做到的。目前容器技术已经被广泛应用在软件开发的各个阶段各个领域,例如用于管理开发环境、用于测试、构建项目和实施持续集成,当然也可以作为传统云平台虚拟化的替代方案,实现更为轻量更具弹性的云计算平台。

虽然上文提到的这些应用场景都是非常有价值的,但还不能体现Docker或是说容器技术如此火爆的原因。我们知道Container通常翻译为容器,但是还有另一个翻译就是集装箱,集装箱被很多人称为是21世纪最伟大的发明之一,它的发明和广泛使用甚至改变了世界的货物运输体系,促进了经济的全球化发展,《集装箱改变世界》这本书就是讲述了集装箱是如何改变世界的。而我们现在所提的容器技术和Docker,是不是也在致力于改变软件的世界,改变我们开发、测试、构建、部署、运维所有这些的现有方式呢?我觉得是有可能的,因为无论是集装箱还是容器技术都为我们带来了两个重要的好处:一致性和隔离

屏幕快照 2015-12-05 下午9.27.22

我们知道一个产品是否可以正常提供服务,只去确保软件本身没有问题是远远不够的,需要同时保证软件、基础设施(例如硬件、操作系统和运行环境)以及配置的正确性和可靠性。而传统的软件开发方式,对于这三个方面的管理是分离的,再加上三者之间错综复杂的关系,就造成了我们常常挂在嘴边的“环境问题”。但是通过使用容器技术,我们如果将软件、基础设施和配置作为一个整体使用容器进行封装,产生一个个已经同时包含了软件以及其运行环境的经过严格测试检验的“包”。这样当部署“包”的时候就不需要再考虑环境的问题,也不需要关心现在部署的是一个Web服务还是一个数据库服务,要做的只是把一个个容器标准化地安装到指定的容器引擎即可。

屏幕快照 2015-12-05 下午9.26.07

可能正是大家都看到了容器技术以及Docker对于软件开发各个领域正在带来的改变,容器技术的生态系统也在经历着一个快速发展的阶段,涉及到开发辅助、集群管理、服务编排、内容发现、云平台搭建等各种工具框架都一一呈现在我们面前,其中像Google和Amazon这样的巨头也都在第一时间发布了各自与容器相关的服务和框架。

1224-王健-3

微服务及相关工具受到追捧

如果大家关注Docker,也肯定会经常听到一种与之相关的架构,也就是微服务架构:

“微服务架构是一种架构模式,它提倡将单一应用程序划分成一组小的服务,服务之间互相协调、互相配合,为用户提供最终价值。每个服务运行在其独立的进程中,服务与服务间采用轻量级的通信机制互相沟通(通常是基于HTTP协议的RESTful API)。每个服务都围绕着具体业务进行构建,并且能够被独立的部署到生产环境、类生产环境等。另外,应当尽量避免统一的、集中式的服务管理机制,对具体的一个服务而言,应根据业务上下文,选择合适的语言、工具对其进行构建。”

这是Martin Fowler给出的对于微服务架构的定义,其中提到了微服务架构的四个特点:

  • 将单一的应用程序划分成一组小的服务
  • 每个服务运行在其独立的进程中
  • 轻量级的通信机制
  • 独立的部署到生产环境

我看过很多非常成功的公司在分享其系统架构演进历程时,往往最后都会落脚于服务拆分和业务服务化。其实这也不算是什么新的概念了,几年前流行的SOA面向服务架构就已经为我们描绘了一个服务化架构的美好前景。那为什么又提出了一种新的微服务架构呢?对于这个问题Martin Fowler在他的那篇《Microservices》也给出了他的回答。简要来说就是虽然这两种技术都是以服务化和组件化为目标,但是架构理念和技术策略上有太多的不同。例如上边提到的微服务架构的主要特点以及其倡导的演进式架构设计,去中心化的架构风格,采用轻量化通信机制,强调独立部署等都是与SOA所提倡的技术和思路有很大区别。微服务架构也更契合现代的技术发展趋势,例如RESTful API的流行,嵌入式应用服务器的应用,持续集成、持续交付的普及,容器技术爆发,组件化的趋势,云平台的发展等。

在引入微服务架构前,系统往往是以一个大的单体应用的形式存在的。此时任何功能的修改都需要重新构建部署整个应用,并且当需要水平扩展时也只能通过扩展整个应用的方式进行,无法做更细粒度的调度和控制。而当切换成微服务架构后,单一功能的修改只需要重新构建部署相应地服务即可,其他服务并不会受到影响。如果某个服务需要水平扩展时,我们也只需要扩展此服务即可。由此可见,微服务架构相比于传统的单体应用架构,可以极大的提高我们的资源利用效率和系统弹性。再加上通过服务化我们可以更容易的以组件的方式组合和重用现有服务,快速地构建出新的服务,使企业和产品更具竞争力。

1224-王健-4

微服务架构还有很多其他的好处:例如我们可以为不同的服务使用异构的技术架构,用最适合的技术解决最适合的业务问题(例如在某些服务中使用关系型数据库,而在某些服务中使用NoSQL数据库);相对于单体应用因为每个服务都更小更简单,所以维护难度和成本也会比传统的大的单体应用要低得多;还有根据康威定律,这种新的服务架构甚至会改变我们软件开发的组织方式向小而精的多功能自组织团队和全栈式演进,前段、后端、运维、DBA这种角色划分方式也许也会因此而成为历史。

微服务架构之所以经常会和容器技术一起被提及,是因为容器技术为微服务架构提供了一个非常匹配的基础设施,从而可以将这种架构的威力最大化的激发出来。设想一下,假如我们有一个产品采用微服务架构,并将每类服务及其运行环境打包为容器,部署于像AWS ECS这类弹性容器服务里。就可以实现通过实时监控每类服务的负载情况,通过自动化的方式快速按需对每类服务基于容器技术进行快速高效的水平扩展或是撤销,这样我们的架构就是一个高度自动化、高弹性、高资源利用率的应用架构,相比于传统的单体应用也将具备很大的竞争优势。

有得必有失,微服务架构有着这么多的好处,但同样也会引入一些新问题,最直接的就是分布式本身所引入的复杂性。例如如何保证服务间的契约,如何快速开发服务,如何保证轻量级通讯协议的可靠性等等。对于这些问题也有着相对应的解决方案,本期雷达就推荐了很多的工具和技术来辅助进行微服务架构下的软件开发。

1224-王健-5

JavaScript工具正在趋于平稳

如果大家关注往期的技术雷达,肯定可以感受到JavaScript的火爆程度。例如在2014年1月刊就提出了“JavaScript战车一往无前”,以及在2014年7月刊又提出了“JavaScript大爆发,框架遍地开花,创新目不暇接”的最新动态。JavaScript如今继续保持着它强劲的势头,但是我们也能感觉到无论是社区还是我们自己团队,大家在经历过暴风雨的波澜后,慢慢平静下来,无论对于JavaScript的框架、工具还是一些最佳实践上的认同也在慢慢的趋于一致。

1224-王健-6

 

ECMAScript 2015目前在雷达上已经被列入了“采用”的阶段。意味着已经没有什么障碍和疑虑再阻止我们使用这个最新的规范,在JavaScript平台上享受一个现代语言为我们带来的简洁、便利和强大。在构建工具和包管理工具的选择上,NPM和Webpack也逐渐成为越来越多人选择的对象。

而对于前端框架的选择上,React.js热的发烫,它喊着“Rethinking Best Practices”的口号,举着组件化的大旗,让每个人目瞪口呆之后,又开始重新审视我们的前端开发实践。如果说容器化实现了基础设施的组件化,而微服务架构提供了架构层面的组件化方案,那ReactJS就把组件化带到了前端开发……哦对了,还有移动开发领域。

1224-王健-7

安全是每一个人的问题

安全越来越受到大家的重视,从“SSL心脏滴血”到“Xcode Ghost”,再到时常出现的用户(商业)隐私信息泄露,钓鱼诈骗,恶性攻击等安全事件。让我们越来越切身地感受到安全对于企业和个人的重要性。并且随着互联网和软件行业的高速发展,安全形势也变得越来越严峻:从硬件安全到操作系统安全,从工具安全到依赖组件的安全, 从网络安全到应用安全,从代码安全到密码安全。任何一个点的疏忽都可能为企业和个人带来毁灭性的打击和伤害。

与安全形势变得越来越严峻形成鲜明对比的就是以往我们在产品设计和开发过程中对于安全无论是在意识上还是在使用的技术上都远远达不到要求。对于安全的关注更多的是以一种“看门人”的方式进行的,也就是在开发和设计过程中往往很少考虑安全的问题,仅仅靠上线前的一段很短的时间,通过一些工具扫描安全漏洞,然后集中修复的方式。这种方式往往让团队处于非常被动的处境,很容易遗漏安全问题,产生安全风险,或是根本没有时间修复所有的安全问题就草率冒险上线。

而现在有越来越多的团队将安全引入到开发的整个生命周期当中,作为一等公民来看待和重视,将安全作为软件质量的一个重要组成部分。例如在软件的早期就通过引入威胁建模(Threat Modeling)的方式为产品做整体的安全建模,并将建模成果以验收说明的方式写入用例文档或是用户故事中。而开发人员也会在实现每个功能时将对安全的关注作为设计和实现的一部分,并为安全编写相关的自动化测试,纳入持续集成系统中保持对于安全的持续验证和关注。

1224-王健-8

关于安全,本期技术雷达也推荐了很多的工具和技术,涉及产品安全、代码安全、密码安全、网络安全、操作系统安全等安全领域。借助于这些工具和理念,可以帮助我们构建出更加安全的产品和服务。

1224-王健-9

 写在最后

以上就是对于本期技术雷达中四个最新动态的一些理解和分析。除此之外,本期的技术雷达还包含了其他很多领域和工具,包括架构设计、大数据、DevOps、数据库技术、持续交付、测试技术等等待你我去探索。

Share

2015.5 技术雷达 | 平台篇

   点击这里可以下载最新中文版本PDF

Apache Spark(spark.apache.org)作为一种快速和通用的大规模数据处理引擎已取得稳步进展。该引擎基于Scala实现,非常适合于那些在多并行操作之间重用数据工作集的应用程序。它即可以作为一个独立集群,也可以作为Hadoop的YARN集群的一部分来工作。它可以从不同的源来访问数据,比如 HDFS,Cassandra,S3 等。不仅如此,Spark还提供了许多更高级的操作符,以便简化数据并行应用程序的开发。作为一种通用的数据处理平台,它使许多更高级别的工具的开发成为可能,如交互式SQL(Spark SQL),实时流媒体(Spark Streaming),机器学习库(MLib),R-on-Spark等。

一段时间以来,Hadoop 社区一直在尝试把低延迟和交互式 SQL 查询能力带到Hadoop平台中(称为SQL-on-Hapdoop)。开源数据库引擎 Cloudera Impala,Apache Drill 和 Facebook的 Presto 都在2014年应运而生。我们认为,SQL-on-Hadoop 这一趋势标志着一个重要的转折,它将 Hadoop 的定位从与数据库互补的批处理,转变为某种可以与之竞争的技术。

Cloudera Impala(cloudera.com/content/cloudera/en/ products-and-services/cdh/impala.html)是早期的SQL-on-Hadoop 平台之一。它是一个基于C++的,支持大规模并行处理的分布式查询引擎。Impala 守护进程是这个平台的核心组件,其负责协调 Impala 集群中跨一个或多个节点间 SQL 查询的执行。 Impala 充分利用了 Hive 的元数据目录来共享两者的数据库和表。Impala 还提供了命令行工具以及 JDBC 和 ODBC 驱动程序供应用程序使用。

密码仍然是一种糟糕的用户认证机制。近来我们看到有公司(如Yahoo!)采用了“无密码”的解决方案——每当你需要从一个新的浏览器登录时,一个一次性验证码会被发送到你的手机来进行认证。如果你仍在使用密码认证,我们推荐您采用能够显著提高安全性的双阶段认证(two-factor authentication)机制。基于时间的一次性密码算法(TOTP)(en.wikipedia.org/wiki/Time-based_One-time_Password_Algorithm)是目前这个领域的标准,在 Google(play.google.com/store/apps/details?id=com.google.android.apps.authenticator2)和 Microsoft(windowsphone.com/en-us/store/app/authenticator/e7994dbc-2336- 4950-91ba-ca22d653759b)智能手机中都这样免费的认证应用。

Apache Kylin (kylin.io),是一个来自 eBay 公司的开源数据分析解决方案,它能够在超大数据集上进行基于 SQL 的多维度分析(OLAP)。Kylin 旨在构建一个基于 Hadoop 的混合 OLAP (HOLAP) 解决方案,最终将能够支持 MOLAP 和 ROLAP 风格的多维分析。你可以使用 Kylin 所提供的立方体设计器来定义立方体,并启动一个离线进程来构建它们。离线进程会进行一个预连接的步骤,将事实表和维度表连接到一个扁平化的结构中。下一个是预聚合阶段,各个单独的立方体被 Map Reduce 任务会构建出来。其结果被存储在 HDFS 序列文件中,之后被载入 HBase 。数据请求可以由基于 SQL 的工具提交 SQL 产生。查询引擎(基于 Apache Calcite)会决定目标数据集是否在 HBase 中存在。如果存在,该引擎会直接访问 HBase 中的目标数据,以次秒级延迟返回结果。如果目标数据集不存在,该引擎会将这些查询转向 Hive(或者是集群中任何其它可以用 SQL 查询 Hadoop 的方案)。

CoreCLR (github.com/dotnet/coreclr) 和 CoreFX (github.com/dotnet/corefx) 是 .NET 的核心平台和框架。虽然算不上是什么新闻,他们最近被微软开源了。一个主要的变化是这些依赖是基于二进制文件来部署的,不再需要事先安装在机器上。这使得并行部署变得容易,允许应用程序可以无冲突的使用不同版本的 .NET 框架。你可以安装 .NET 依赖到任何环境中,基于 .NET 编写代码成为了一个实现细节。从外部依赖的角度来看,一个用.NET实现的工具与用 C 语言编写的东西并没有什么不同,这就使它成为编写通用应用程序和工具的一个更有吸引力的选择。CoreFX 也已被分解为独立的 NuGet 依赖,从而使应用能够按需使用,这让 .NET 的应用和库占的空间的更小,并使得替换部分框架更加容易。

Heroku 用它的12要素应用模型改变了我们关于构建、部署、托管 Web 应用的方式。Deis (deis.io) 将 Heroku PaaS 模型封装到一个开源框架中,部署在可被托管在任何地方的 Docker 容器中。Deis 仍在进化当中,但对于那些符合12要素模型的应用来说,它具备大大简化部署,并在你自选的环境中进行托管的潜力。Deis 也已成为 Docker 周边丰富的平台和工具生态系统中的又一鲜活事例。

预测分析在越来越多的产品中被使用,而且通常出现在面向最终用户的功能上。H2O (docs.0xdata.com) 是一套非常有意思的新开源工具包(其背后是一家创业公司),因为其易用的用户界面设计,使得预测分析对项目组更可用。同时它还集成了数据科学家最喜欢的一些工具:R 和 Python 语言,以及 Hadoop 和 Spark。H2O提供了很高的性能,并且依我们的经验,非常易于在运行时集成,特别是在基于 Java 虚拟机的平台上。

当 Oracle 决定停止对 Sun 公司的 OpenSSO(一个开源的访问管理平台)进行开发时,ForgeRock 决定接管它并将它集成进他们的 Open Identity Suite 中。现在它被命名为 OpenAM (forgerock.com/ products/open-identity-stack/openam) ,成为了一个支撑 OpenID 连接和 SAML 2.0的可扩展的开放源码平台。不过,由于 OpenAM 历史悠久,导致它的代码库很庞大,并且文档也很难理解。希望在不久后,一个更轻量级的,对自动化部署和配置提供更好支持的替代方案将会出现。

Spark 是基于云的互联设备全栈解决方案,Spark Photon 是一个带 wifi 模块的微控制器,而 Spark electron 是连接到移动网络的变体。Spark 操作系统为这些设备添加了 REST API 服务。这套解决方案降低了进入物联网,并构建你自己的可连接设备的门槛。

时间序列数据库(TSDB)是一种针对时间序列数据的处理做了优化的系统。它允许用户对各种以时间序列组织起来的数据库对象进行 CRUD 操作。同时它还可以在整个序列上执行统计计算。虽然时间序列数据库不是一个新的技术,但是我们还是在这些数据库应用中看到了一些新的热点,尤其是在物联网应用领域。在许多开源和商业平台(比如OpenTSDB, InfluxDB, Druid, BlueFloodDB 等等)的促进下,时间序列数据库技术发展迅猛。另外还值得一提的是,其中一些数据库产品还使用了类似 Cassandra 和 HBase 的分布式数据库作为他们的底层存储引擎。

容器技术,PhoenixServer 以及持续交付的崛起已经开始让我们摆脱昔日部署 Web 应用的方式。传统方式是我们需要构建出应用工件,然后将工件安装到应用服务器中。这种方式会导致较长的反馈周期,构建时间的变长,以及在生产环境中管理这些应用服务器的开销变大。除此之外,这些应用服务器也很难做自动化。在与我们一同工作的很多团队中,开始倾向于将 HTTP 服务器嵌入到应用中。有很多可以选择的嵌入式服务器:Jetty, SimpleWeb, Webbit 和 Owin 等。更容易做自动化,更容易做部署,对基础设施的投入也会减少,因此我们推荐在未来的项目中使用嵌入式的应用服务器而不是传统的应用服务器。

Google 从2009年开发了一个实验性质的协议 SPDY (chromium.org/spdy/spdy-whitepaper),作为一个替代协议,它用于解决 HTTP/1.1中的一些性能短板。新的 HTTP/2 标准协议包含了很多 SPDY 中性能优化的关键特性,Google 已经宣布从2016年初就会停止在浏览器中支持 SPDY。因此,如果你的应用需要 SPDY 中的特性,我们推荐你去尝试 HTTP/2。

点击这里可以下载最新中文版本PDF

Share