微信号:infoqchina

介绍:有内容的技术社区媒体

Q新闻丨开源等于安全吗?高可扩展分布式应用程序的架构原则;各种类型的Kanban介绍

2015-11-03 08:18 InfoQ
1
汽车软件问题引起争议
开源真的等于安全吗?


今年,汽车圈的那些事占据着媒体头条,比如黑客入侵吉普车、大众汽车在排放测试上作弊, 这说明公众开始思索汽车的软件问题,这是前所未有的。有些专家可能会争辩说,强制这些软件开源,是一个解决办法。虽然将这些软件置于公众的审视之下是有明显好处的,但开放代码这种行为本身,并不能给你带来保障。就像Sam Liles在一封电子邮件中给我解释的那样,开源并没有阻止“破壳(ShellShock)”漏洞的发生。


Liles教授以前是普渡大学数字取证领域的教授,在那儿工作时,他和他的学生研究过汽车和其他物联网设备的安全。他说,多重防御的思想已经落伍,我们无法再靠多设几层安全屏障来保护自己。举个例子,我们的手机和其他个人设备,知道我们的一切:我们去过哪里,和谁联系过。这些设备,以及存在其中的所有信息,已经渗透到我们生活和工作的方方面面。一部被入侵的手机,可以挖出各种隐藏的信息,或者把威胁传播给与之相连的其他设备。


这些设备的存量本身就是个威胁。“如果发生了安全事件,谁应为此负责?”Liles问。就我们这个问题来说,谁来审查那些代码?在《大教堂和市集》中,Eric S. Raymond写道,“只要给予足够的关注,所有的bug都会显形”,他称之为Linus定律,但我们不能指望什么软件都有足够的关注度。像OpenSSL这样成名已久的重要项目都因为缺乏资金而无法预防像“心脏滴血(Heartbleed)”这样的Bug,那运行在你设备中的你都已习以为常的成千上万行代码,又指望谁去审查呢?


2011年,美国国家航空航天局和美国高速公路安全管理局针对丰田汽车意外加速事件进行了调查,结果显示并没有证据表明电子设备的失控能导致大量意外加速,但尽管如此,其他研究人员还是找到了能让汽车产生加速的软件方法。“如果电源管理单元被攻破,”IOActive的报告指出,"加速度就会迅速变化,汽车将处于极度危险中。"毫无疑问,软件是现代汽车安全的一个至关重要的组件。


然而,像Liles小组所做的那类研究还是不多见的。单纯分析软件是一件困难的事。“系统中几乎从来不考虑集成一个用于搜集取证的模块,为了使证据有法律效力,必须要使用逆向工程的手段来取证。”Liles说。此外,物联网给汽车带来的威胁在不断变化,所以我们的研究方向也要随之改变。“很多陈旧的信息保护手段,安全规则和教条,有时还称之为科学的东西,都是基于谬见、伪事实和过时的技术概念而来的。”


所以,开源软件要如何适应这种形势?无论是否开源,偶发的bug总是会出现,有时还很严重。“心脏滴血(Heartbleed)”、“破壳(ShellShock)”,以及开源软件中其他备受瞩目的漏洞都在告诉我们,这就是现实。开源更容易使软件被恶意利用,而只有在我们能验证软件的行为和代码的意图一致时,其开放性才能带来好处。这一点将愈发重要,因为汽车正在变成和我们的手机和移动互联网服务相连的开放系统。


2
四维度十原则
高可扩展分布式应用程序的架构原则


Elastisys云平台诞生于瑞典默奥大学的分布式系统研究小组。它由一组以预测性扩展引擎为中心的工具组成,可以自动扩展云部署。近日,其官方网站发表了一篇文章,介绍他们在高可扩展分布式应用程序设计和开发方面的经验。


他们将可扩展性分成了如下四个维度:


性能可扩展:性能无法完全实现线性扩展,但要尽量使用具有并发性和异步性的组件。具备完成通知功能的工作队列要优于同步连接到数据库。


可用性可扩展:CAP理论表明,分布式系统无法同时提供一致性、可用性和分区容错性保证。许多大规模Web应用程序都为了可用性和分区容错性而牺牲了强一致性,而后者则有赖于最终一致性来保证。


维护可扩展:软件和服务器都需要维护。在使用平台&工具监控和更新应用程序时,要尽可能地自动化。


成本可扩展:总拥有成本包括开发、维护和运营支出。在设计一个系统时,要在重用现有组件和完全新开发组件之间进行权衡。现有组件很少能完全满足需求,但修改现有组件的成本还是可能低于开发一个完全不同的方案。另外,使用符合行业标准的技术使组织更容易聘到专家,而发布独有的开源方案则可能帮助组织从社区中挖掘人才。


以上各项,他们在设计应用程序时都会考虑和权衡。下面是他们根据上述内容总结出的10个设计原则:


  • 避免单点故障:任何东西都要有两个。这增加了成本和复杂度,但却能在可用性和负载性能上获益。而且,这有助于设计者采用一种分布式优先的思维。

  • 横向扩展,而不是纵向扩展:升级服务器(纵向)的成本是指数增长的,而增加另一台商用服务器(横向)的成本是线性增长的。

  • 尽量减少应用程序核心所需要完成的工作。

  • API优先:将应用程序视为一个提供API的服务,而且,不假定服务的客户端类型(手机应用、Web站点、桌面应用程序)。

  • 总是缓存。

  • 提供尽可能新的数据:用户可能不需要立即看到最新的数据,最终一致性可以带来更高的可用性。

  • 设计时要考虑维护和自动化:不要低估应用程序维护所需要的时间和工作量。软件首次公开发布是一个值得称赞的里程碑,但也标志着真正的工作要开始了。

  • 宁异步,不同步。

  • 努力实现无状态:状态信息要保存在尽可能少的地方,而且要保存在专门设计的组件中。

  • 为故障做好准备:将故障对终端用户的影响最小化。


3
最具创意的5种Kanban
各种类型的Kanban介绍


Kanban可以用来组织企业的很多方面,并应当针对性地进行设计。Dovilė Misevičiūtė,ISM管理与经济大学的研究经理分享了一篇博文最具创意的五种Kanban。她把Kanban描述为:


节省空间:


有时候团队在创建Kanban时面临空间不足的问题。Olivier Lafontan,AXA的Agile、Kanban和Lean创业教练,为此提出了解决方案。他提议把面板变成正方形。不同于传统的方式把任务从左边的列移动到右边的列,他建议按顺时针进行移动。


Arrow Kanban面板:


Tomas Rybing,Aptilo Networks的项目管理总监,在他最近的博客中,分享了名为‘Arrow’的自定义Kanban的概念。Arrow基于优先级金字塔(priority pyramids)方法。Arrow把待办事项可视化,结合了把工作过程可视化的Kanban。欲知详情,可见InfoQ网站上关于Arrow Kanban面板的文章。


人力资源网络:


Kanban也可用于人力资源部门。Jennifer Vaaler,Transpire Life的小型企业效率专家, 分享了人力资源网状Kanban。该Kanban转化为类似蜘蛛网的形状,网络的每一部分代表不同的工作职位,每行代表招聘过程中的一个步骤。潜在的候选人作为任务卡片,从最初的接触移动到可能的工作邀约,或者在过程中当证实他们不胜任时被丢弃。


笔记本:


该Kanban适用于个人Kanban用户。Patty,针对化疗患者的Layers of Love,分享了她创建整个面板的笔记本的实验。

她提议把整个面板放入你的笔记本中,使得它便于携带,总在手边。她还是使用即时贴,如果需要,为不同的活动准备不同的面板。当证明变得可移动更加有效时,实在没有必要抱定面板的主意。


强大的乐高积木:


该Kanban是Drew的一个团队的实验。此面板受到乐高积木的启发。面板相当简单——分成三个简单的部分,要做、在做和完成。每个任务卡片包含任务的数量、客户名称和简短描述。任务分配通过彩色编码块进行,其数量受限于每位团队成员是否有空。


今日文章推荐


  1. OPPO服务化架构系统监控难题解决方案

  2. 技术债务管理,是什么&怎么做!

  3. 『1024』这个程序员节,聊聊程序员的自我进阶

  4. 两天三人一APP,谈谈小咖秀背后的技术故事


  • 点击文章标题直接获取内容👆



版权归属InfoQ,禁止私自抄袭转载。

回复关键词React | 架构师 | 运维 | 云 | 开源 | 物联网 | Kubernetes | 架构 | 人工智能 | Kafka | Docker | Netty | CoreOS | QCon | Github | Swift | 敏捷 | 语言 | 程序员

投稿:editors@cn.infoq.com

合作QQ:1073600161



 
InfoQ 更多文章 Facebook如何实现PB级别数据库自动化备份 学术派Google软件工程师Matt Welsh谈移动开发趋势 Spotify为什么要使用一些“无聊”的技术? 妹纸们放假了,汉纸们做啥? 大多数重构可以避免
猜您喜欢 Native\/WebView\/Hybird 区别 学习python的几个好习惯 The Swift Programming Language--语言指南--基本运算符 【南京的雪】久违了,雪 这才是程序猿的真相... 最后竟然眼泪掉下来...