ArchUnit

写在前面

ThoughtWorks每年都会出品两期技术雷达,这是一份关于科技行业的技术趋势报告,在四个象限:技术、平台、工具以及语言和框架对每一个条目(Blip)做采用、试验、评估、暂缓的建议。(参考阅读:解读技术雷达的正确姿势

一直以来,我们都未对每一个Blip做进一步的解读,而这次决定尝试一个新的专栏——《雷达哔哔哔》,由作者根据自己实践与理解,对雷达中部分条目作出解析,致力于用一篇篇短小精悍的文字,帮助读者加深对雷达的理解。

今天是《雷达哔哔哔》的第三篇,依然关注架构,Blip是ArchUnit

位置

2018年11月第19期技术雷达,工具象限,建议试验

目标受众:

系统架构师,技术管理者,开发人员

关注问题:

  • 如何在Java系统架构下,应用架构适应度函数(Architectural fitness function)来驱动架构演进?
  • 如何在Java系统架构下,做系统演进后架构守护,减缓系统再次腐化?

解读:

在上一期我们介绍了架构适应度函数(Architectural fitness function),也提到了ArchUnit,这期就来详细介绍一下。

ArchUnit是用来检查架构特征的Java测试库,比如包与类的依赖关系、注解、甚至是调用层级一致性。它可以附加在现有的测试方案中,以单元测试的方式运行,但目前只能用于Java架构。

ArchUnit测试套件可以合并到持续集成环境及部署流水线中,使我们可以更容易地利用架构适应度函数实现演进式架构。我们来看看ArchUnit都能做些什么:

  • Package Dependency Checks

  • Class Dependency Checks

  • Class and Package Containment Checks

  • Inheritance Checks

  • Annotation Checks

  • Layer Checks

  • Cycle Checks

想要了解更多,可以移步【官方用户指南】

最后不得不说一下,架构优劣不取决于是否遵循某一个标准,而是应该取决于能否支撑业务的需要。约束越强,灵活度越低,架构就会越加僵硬,缺少适应性,产生冗余。

所以工具本身只是赋予了我们约束架构的能力。但是能否正确地使用这种能力通过Fitness Function和演进式架构来促进架构对于业务的匹配度和适应度;还是截然相反的错误地滥用这种能力成为所谓的管理手段或是技术上的噱头,最终导致系统架构僵化,无法支撑业务需要,决定权还是在我们架构师手中。

不要过度神话工具,也不要让工具替我们背锅,工具只是工具,工具本身没有对错。

工具:

ArchUnit

延展阅读:

👇👇👇订阅最新期技术雷达

Share

Lightweight Architecture Decision Records | 雷达哔哔哔

写在前面

ThoughtWorks每年都会出品两期技术雷达,这是一份关于科技行业的技术趋势报告,在四个象限:技术、平台、工具以及语言和框架对每一个条目(Blip)做采用、试验、评估、暂缓的建议。(参考阅读:解读技术雷达的正确姿势

一直以来,我们都未对每一个Blip做进一步的解读,而这次决定尝试一个新的专栏——《雷达哔哔哔》,由作者根据自己实践与理解,对雷达中部分条目作出解析,致力于用一篇篇短小精悍的文字,帮助读者加深对雷达的理解。

今天是《雷达哔哔哔》的第一篇,Blip是Lightweight Architecture Decision Records

位置

2018年5月第18期技术雷达,技术象限,建议试验

目标受众:

  • 系统架构师,技术管理者,开发设计人员

关注问题:

  • 传统的重文档编写维护量大,随着业务发展,很难保持同步
  • 在一些敏捷项目中,随着关键文档的缺失、项目Knowledge及决策丢失导致长生命周期的项目知识传递问题

解决方案:

  • 使用“ Lightweight Architecture Decision Records”(轻量级架构决策记录)来记录项目的重要决策,并将其与代码等其他项目资产一样,纳入到版本控制系统之中。

解读:

“项目要不要写文档”一直是一个很有争议的问题。在过去,项目一般都要写众多的文档,类似于需求说明书、概要设计、详细设计、数据库设计、等balabala设计……而这些文档的作用往往只是为了【过评审】或是【招投标】,写文档的形式也更多是简单的复制粘贴。

项目拿下了,过审了,一旦开动起来,文档反而就被束之高阁,再也无人过问了。

很多人没日没夜地写着千篇一律的文档、文档、文档……终于有一天,盼来了敏捷,并看到了敏捷宣言中硕大的一句:

(敏捷宣言)

唉呀妈呀,终于见到了亲人,从此高举着敏捷的大旗,与文档势不两立。

再有人敢提起写文档,就把早已准备好的“敏捷大棒”从身后掏出来,劈头就是一棒槌……

不得不说,敏捷又一次背了口黑锅。敏捷宣言所推崇的并不是简单的不写文档,而是认为之前那种写文档的方式根本没有体现出其应有的价值。还 不如代码写的漂亮些,测试写的完备些,让代码和测试成为真正有价值的活文档。

而这,相对于简单的复制粘贴攒文档,对于团队的要求反而更高了。

世间万物,物极必反。

随着时间的推移,再好的敏捷团队也会出现知识流失的问题,尽管有着完备的测试和易读的代码,但这些毕竟过于细节,无法快速还原当时设计或重构时的所有上下文。

所以技术雷达推荐使用“ Lightweight Architecture Decision Records”来记录项目的重要决策,相比于传统文档,它最大的特点就是轻量(Lightweight),关注于创造价值而不是遵循流程。 让我们看个ADR的模板:

(ADR Template)

同时技术雷达也建议我们不要将ADR束之高阁、放到Wiki或是文档库中。而是随着代码放到Git或其他版本控制工具里,这样既可以保持最大程度与代码同步,又能跟踪Decision的变更历史。

推荐的Adr-Tools工具,可以帮助我们更容易的做到这些。

相关Blip及延展阅读:

工具:

GitHub – npryce/adr-tools: Command-line tools for working with Architecture Decision Records

Share

一个AR Tech Radar的诞生

什么是AR Tech Radar

技术雷达是ThoughtWorks每年出品两期的技术趋势报告,一般来说大家看到的雷达都是文档形式,其中有一张技术全景图,以及每个技术点的成熟度分析。而AR技术雷达就是在原始文档的基础上,利用AR技术将其立体化呈现,并在其中添加互动元素。

为什么要做AR Tech Radar

  1. 技术雷达一直以来都是文档的形式呈现,如果能通过包含在内的最新技术呈现出来,岂不是更能体现技术雷达的意义。同时也能增加技术雷达的交互和科技感。
  2. XR Community作为AR/VR等技术的探索者,AR技术雷达是我们社区内部产品的第一步尝试。
  3. 我们也不知道为什么,就是想做AR Tech Radar。

AR Tech Radar的技术选型

目前市面上能做AR的技术有很多,基本上每家大公司都有自己的AR技术。为什么我们会选择ARKit呢?(ARKit是苹果做AR软件开发的一个工具,使开发者能为iOS设备开发增强现实应用。)

之所以选择ARKit一个很重要的原因就是懒,只想选一个学习成本比较低的技术。

其实AR技术强依赖于承载它的硬件,所以选择AR技术其实就是在选择硬件平台。我们期望能使用一个广泛的平台,让AR技术雷达被更多的人接触到。目前AR硬件平台使用最广泛,也最容易让用户接触到的就是iOS,所以我们选择了ARKit。

其中还有一些其他的人气技术,比如:

  • ARCore,它是Google推出的运行在Android上的技术,但目前只有几款顶配的Android手机可以运行。
  • Hololens,它是微软的AR眼镜,购买成本较高,很难被普通用户接触到。
  • Unity,它支持iOS和Android跨平台。

那为什么我们没有选择在unity上进行AR开发,让它同时支持iOS和android呢?一个原因是ARKit和ARCore是才出来的新技术,它在unity上的兼容性和使用上肯定有很多未知的坑,我们期望使用比较稳定的平台。另外一个原因是,我们期望尝试用原生开发,以便更深刻的体验AR开发的过程。今后我们会尝试使用例如unity等工具进行开发,然后和原生开发做一个对比。

如何开发AR Tech Radar

准备

ARKit是苹果的技术,语言首选是Swift。 硬件需要支持ARKit的一台Mac和一部iOS设备。因为ARKit不支持模拟器运行,所以必须使用真机进行全程的开发调试。 开发软件是Xcode。

前期构想

做AR开发需要有两部分准备,一部分是本身的编程,另外一部分就是3D建模和空间相关的知识。编程不必多说,只要会Swift就能开始。3D建模不是我们的长项,所以前期我们做了很多调查,比如自己使用3D建模软件做一个雷达模型,或者去购买别人做好的雷达模型,或者外包给第三方公司做一个3D模型,再或者找会3D建模的同学加入我们。

但这些方案都被我们否决了,原因有很多,比如我们的经费有限,不能支持我们去找外包,也没有现成的模型给我们购买。而自己去学习3D建模的学习时间也长,同时也没找到会3D建模的同学。

因此我们决定用ARKit支持的形状来组合一个雷达。

我们曾经设想过很多次AR技术雷达应该长什么样。

比如罗马斗兽场的样子,让技术每层递进。

或者是一个圆球,人站在球里面,被周围的技术包围,大概像这样:

再或者,它应该是一个立在你面前的展台,技术雷达就摆在用户面前,大概像这样:

最终这些想法都被我们暂时搁置了,最主要的原因是我们没有能力和人手去实现那些炫酷的样子,并且我们觉得技术雷达就应该用它最朴素的样子展示给大家,应该被大家关注的是技术雷达的内容,而不是这个3D物体。所以最终我们决定用一个圆饼来展示技术雷达。

开发

首先,3D建模不是我们的长项,所以我们选用了ARKit支持的基本形状来组合出一个技术雷达的大饼。因此,我们使用了一个圆柱体和三个圆管,如下图。正中间是一个圆柱,用三个圆管把圆柱包围起来,就形成了雷达圆饼。

接着,为了让整个雷达看起来更立体,我们使用了圆球来作为每个技术的标示点,同时让标题浮在圆球的正上方。如下图。

我才不会告诉你,每个技术标示点在第一版的设计中是圆锥形的,看起来像雷达上的一坨坨屎。请看下图。

然后就是添加交互,让用户在点击某一个圆球的时候弹出它的具体阐述。就像下图一样。我们在圆球的正上方弹出一个半透明白板,并把标题和内容放在上面。 白板上的字不同于圆球上的标题,它是印在平面上的,而不像标题是3D立体的。因为大段的文字不适合全部做成3D立体的字,这对资源的消耗和3D的计算是很大的。所以我们利用3D纹理贴图,把文字描述贴到了白板上。

数据

最后就是如何添加数据,我们希望这个AR技术雷达能运用到每一年的技术雷达,这就要求我们添加进去的数据是支持更新的。

所以我们使用了一个单独的文件来存储每一期的所有技术,文件内容包含了所有技术相关的信息,比如名字、详细介绍、它所处的象限、它的分类等等。

这样的好处就是下一次的雷达技术出来之后,我们只需要更新这个独立的文件就可以看到最新的AR技术雷达了。

3D开发过程中遇到的困难与趣事

遇到的第一个奇葩事件就是,第一次我们添加了一个物体,可是在摄像头里面怎么都找不到,后来我们无意中把镜头对着天空突然发现那个物体在空中飘着。原因就是ARKit世界里面的尺寸是和现实世界一样的,单位是米,而我们的离地高度设的是3米,因此它就跑到空中去了。

另一个和这个是相似的,我们加了一个圆管放在地上,可是在地上怎么也找不到那个圆管。后来我们才发现,我们的圆管的尺寸太大了,把我们全部包在圆管里面了。

第三个有意思的事情是,我们添加了一个平面,上面写了一些东西,可是我们在镜头里面却怎么也找不到这个平面。通过各种debug和调查研究,才发现,我们在平面的背面,原来对于没有厚度的平面,只能在正面才能看得见。

还有一个比较棘手的问题就是,比如有些物体需要旋转两个90度再加上一些变换才能达到我们想要的位置。这对空间想象能力的要求就比较高,我们尝试了很多种旋转和变换,才最终找到了想要的位置。

未来的发展

我们期望AR技术雷达能发展成为每次技术雷达发布的官方AR应用,通过不同的途径和不同的体验让更多的人了解技术雷达,让人们能和技术雷达有一些有意义的互动。

所以未来我们期望能不断完善AR技术雷达,让它成为一个炫酷的、交互式很强的应用。

打开脑洞想象一下,通过使用AR技术雷达,你不仅可以看到每次更新的新技术、还能够通过一些交互直观的看到它的历史轨迹、应用场景以及具体实践,是不是一件很酷的事情?


更多精彩洞见,请关注微信公众号:思特沃克

Share

CEO要学习写代码吗?

法国兴业银行的CEO在努力学习Python

偶然间看到一篇文章,法国兴业银行的CEO Frederic Oudea,说54岁的自己正在学习写代码

“数字市场瞬息万变,必须努力学习来适应变化。我们正在认真对待这一挑战,并认识到有必要改变模式,并在文化上接受新技术。对于我来说,了解编码手段的确切性也非常重要,所以我花了几个小时用Python编写代码,这是数据技术的两种语言之一。”

——法国兴业银行的CEO Frederic Oudea

Frederic Oudea并不是唯一主张学习写代码的CEO。Mana AHL的CEO Sandy Rattray,通用电气公司的前CEO Jeff Immelt,苹果的CEO Tim Cook,都持有此主张。

(图片来自:http://t.cn/R3uvOwL

技术出身的CEO们还将领衔下一个十年的技术发展

当今科技巨头的CEO们,微软的比尔盖茨与现任纳德拉,Google的拉里佩奇和现任皮查伊,Facebook的扎克伯格,Amazon的贝佐斯, Adobe的纳拉延,SpaceX的埃隆马斯克, 中国的雷军、李彦宏、马化腾,都是技术背景,能卷起袖子解决问题。

《软件随想录》中这样记录比尔盖茨,“你不要糊弄他,哪怕是一分钟,因为他是一个程序员,一个真正、现实的程序员”。作为十大巨头里唯一不是技术出身的马云,则在公开演讲中表示:“因为我不是技术出身,所以我对待技术的态度更严谨认真。”

这些工程师出身的CEO们,不仅仅在过去的10年中创造了商业奇迹,更重要的是,在未来10年的演进式交互、增强人类、平台兴起、安全和隐私、智能机器人等重要科技领域,这些科技巨头更是遥遥领先。在Google I/O 2018大会上,靠预约订座“语惊四座”的Google语音助手、应用AI+AR的提供智能推荐的Google地图导航,都令人惊叹不已。

非技术背景、没碰过代码的传统CEO们,面临难题

科技公司技术大会的狂欢,皮查伊们的风度翩翩侃侃而谈,不免让过去未学过技术、没碰过代码的传统CEO们,坐立难安。

除了意识上的焦虑和强烈的危机感,欠缺技术认知的CEO常常也会面临以下难题:

  • 无法评估创意风险,错失创新时机或者被人忽悠。传统公司深知创新的重要性,但当面临一些新创意时,因为不懂技术无法评价技术风险、判断可行性。要么被忽悠——“伟大的创意就差一个程序员了”,实际结果也许是这伟大创意只能写个科幻小说;要么“我们再看看吧”,错过最好的市场时机。
  • 无法做出新业务的成本核算,进行业务决策。很多传统企业里面IT很弱或者原来IT都是外包。自己也不懂的情况下,很难评估研发工作量、技术要求、研发节点,导致人员规模,成本核算都不靠谱。因而无法做出决策,指导战略项目的进行。
  • 无法构建业务必须的团队和能力。想建立一个符合要求的研发团队,可招人都不知道怎么招;想找一个懂技术的来当合伙人解决上述问题,却没有能力评估他是否有能力干这事。

CEO是否要学习写代码?扎克伯格说YES

虽然大多数人倾向于“CEO对技术有良好直觉和敏感性”就够了,但Facebook的CEO扎克伯格,却坚持CEO应该向开头提到的Frederic Oudea一样学习写代码。其中有三个理由值得深思:

(图片来自:http://t.cn/R3u4qY5)

  • 学写代码,能够提出好问题,“防忽悠”。“如果你聘请某人为你建造房屋,但你从未试图自己建造房屋,你将不知道合理的成本和应该花多长时间。任何涉及编码的项目都是如此。如果你没有知识基础,那么你有被误导的风险。花时间学习基础知识可以帮助你提出正确的问题,并确定你知道他们在做什么。”
  • 理解市场上的技术。阅读技术理论是一回事,辨别其是真正创新还是市场炒作是另一回事。任何一个新技术从提出到创造商业价值会经历一个烟斗曲线。在AI大火的2017年和全民热捧区块链的2018年,ThoughtWorks技术雷达则指出“太火的东西,我们往往需要克制对待”。技术商业化的时机是否真地来到?只有“亲手实践”一下才能领悟。
  • 学编程会迫使我们将自己置于“学习者”模式。过去线性逻辑的思维,在AI的时代,似乎不适用了。比如,过去谈起预测,大家就觉得应该预测得准确;当CEO想启动采纳机器学习技术时,出于惯性思维会问:“这个预测的准确率可以达到多少呢”。然而,这却是个错误的命题。“机器学习是一种优化任务。优化任务的目标不是找到‘正确’的答案,而是找到一个‘看起来不错’的答案。” 单看书很难理解,只有动手去了解背后的算法逻辑,动手让代码跑一跑结果,才能理解从此切换思维模式。将来类似的技术还会有很多,必须通过实践体验来学习适应新的思维模式。

对技术拥有好奇心、拥抱学习新技术,已经是CEO们的共识

是否真地要去写代码,可能是一个问号,但毫无疑问,“对技术保持好奇心、拥抱学习新技术,跟上技术趋势”已经是CEO们的共识。 麻省理工学院的研究科学家斯蒂芬妮沃纳说:“技术就是一切。”在她的研究结果中,数字技术深深扎根于业务中,其影响非常广泛,是CEO必须明确关注的问题。

商业云通信公司Vonage,不断发展的技术促使消费者的语音互联网协议(VoIP)平台在短短几年内发生了巨大的转变。该公司的CEO Alan Masarek,也是前谷歌高管,表示:“我们绝对需要去了解科技的任何变迁,了解如何最好地采用科技来改进我们的工作。”

麦肯锡的一份CEO指南中,则建议CEO应该深入了解软件开发的技术,学习软件产品的依赖的基础设施、如何开发和如何管理的具体实践。

我们曾看到一位传统公司的CEO,在他的案头,放着亚马逊的Echo语音设备,并很习惯地和语音助手Alexa时不时聊个天。

与其焦虑,不如“Just Do It”

未来就像一盒巧克力,不尝试怎么知道?如果你是有胆识的CEO:

1. 转变心态,勇于“承认自己的未知”

Celia Pronto是Casual Dining Group的CDO。他表示:“真正接受技术的人往往会问很多问题。他们知道‘承认自己无知’,并不可耻。”

硅谷著名数字营销公司SparkToro的CEO Rand Fishkin,在他的博客中也坦承:

我至今仍在为缺乏工作中的某些知识而极度的难为情。在做决策时,会问一些很傻丢面子的问题。但关键是,至少是对我,要承认自己是个无知,正确的看待这种批评,不再恐惧,敢于说“我不知道,但我会弄清楚。”

2. 以初学者心态,持续跟踪技术动态,发展对技术的良好直觉

对于精通技术的人来说,最大的好处就是在一个特定的商业环境中,围绕什么是战略性的,什么是非战略性的,有敏锐、良好的直觉。这需要强烈的好奇心,并养成通过技术雷达去了解技术趋势,持续跟踪技术动态的习惯,长期积累。了解大的技术板块,关键技术的现状、所处烟斗曲线的位置、商业场景、对自己组织的影响、自身需要什么样的人才和构建什么样能力等。即使不能真正动手实现技术,也能保证在需要决策时,可以提出正确的问题。

3. 深入了解技术,通过动手去体验建立“未来”思维

了解一个技术是如何从默默无闻发展到全民热炒,只有理清发展脉络,知道它目前所处的状态、技术成熟度以及市场支持度,才能不被泡沫所迷惑。

千闻不如一试,如小扎所说,抱着好奇心,不妨和身边的技术Geek一起,6月2日,来深圳技术雷达峰会,动手写写代码亲自体验下区块链、机器学习解决问题的过程,重构“学习”思维,获得最新技术洞察,增强对未来的信心。

Share

2018年5月期技术雷达正式发布!

ThoughtWorks每年都会出品两期技术雷达,这是一份关于技术趋势的报告,由 ThoughtWorks 技术战略委员会(TAB)经由多番正式讨论给出,它以独特的雷达形式对各类最新技术的成熟度进行评估并给出建议,为从程序员到CTO的利益相关者提供参考。

它比那些我们能在市面上见到的其他技术行情和预测报告更加具体、更具可操作性,因为它不仅涉及到新技术大趋势,更有细致到类库和工具的推荐和评论,因此更容易落地。经过半年的追踪与沉淀,ThoughtWorks TAB(ThoughtWorks技术咨询委员会)根据我们在多个行业中的实践案例,为技术者产出了第十八期技术雷达,对百余个技术条目进行分析,阐述它们目前的成熟度,并提供了相应的技术选型建议。

本期四大主题

浏览器增强,服务端式微

为了实现应用逻辑,浏览器在持续扩展成为部署目标的能力。当平台能照顾好横切关注点和非功能性需求的同时,我们注意到后端逻辑的复杂性有逐步降低的趋势。 WebAssembly 的引入为web应用创建逻辑提供了新的语言选择,同时把处理过程更加推向金属侧(以及GPU)。 Web Bluetooth让浏览器能够处理那些原本是本地应用才能处理的功能,而且我们看到越来越多像 CSS Grid Layout和 CSS Modules这样的开发标准正在替换掉自定义的库。对更好用户体验的追求,正在持续地把功能装进浏览器里,许多后端服务因此变得越来越薄,复杂性也因而降低。

不断蔓延的云环境复杂性

虽然AWS继续凭借令人眼花缭乱的新服务保持领先,但我们逐渐看到 Google Cloud Platform (GCP)和 Microsoft Azure 已经成为可行的替代方案。像 Kubernetes 这样的抽象层以及持续交付和基础设施即代码这样的实践,能支持更容易的演进式变化,从而促进云环境之间的过渡。但随着 PolyCloud (这允许组织根据差异化的功能在多个供应商之间进行挑选)以及越来越多的监管和隐私问题的出现,云策略必然会变得更加复杂。例如,许多欧盟国家现在依法对数据所在地做出要求。这使得数据存储的管辖权和其主机的管理策略成为评估云计算环境的新维度。云计算环境的可选范围也在扩大,比如在“函数即服务”和“管理更长寿命集群”这两者之间,就可以选择提供了“容器即服务”(CaaS) 的 AWS Fargate 这个有趣的选项。虽然各个组织对云技术的应用日臻成熟,但伴随使用这些新技术构建真实解决方案的,是逐渐蔓延又无法避免的复杂性。

信任但要验证

对于几乎所有的软件开发来说,安全问题仍然是至关重要的。当前我们观察到传统的“全局权限管理”的安全策略正在转变为更为细致的本地化方法。现在许多系统会在更小的领域内管理信任,并在不同系统之间使用一些新的机制创建可传递的信任。其理念正在由“永远不信任领域外所有东西”以及“从不验证领域内任何东西”转变为“信任但是需要验证领域内外任何东西”——也就是说可以假设和系统其它部分有本意良好的互动,但一定要在本地验证这份信任。这使得团队可以对自己的基础设施、设备和应用程序栈有高度的权限控制,从而实现高度可视化,并可以在必要时候提供高级访问护栏。类似 Scout2的工具以及 BeyondCorp 这样的技术反映了关于信任更成熟的视角。我们欢迎这种向本地化管理的转变,特别是当工具和自动化策略可以确保同等或更好的合规性时。

物联网的发展

物联网(IoT)生态系统持续稳步发展,关键成功因素包括安全和成熟的工程实践。我们看到了整个物联网生态系统的增长,从设备上的操作系统到连接标准,尤其是基于云服务的设备管理和数据处理。我们看到了一些成熟的工具和框架,支持良好的工程实践,比如持续交付、部署以及为实现最终广泛使用的大量其他必要实践。除了主要的云服务提供商——包括 Google IoT Core ,AWS IoT 和 Microsoft Azure IoT Hub ——像阿里巴巴和阿里云这样的公司也在大力投资物联网 PaaS 解决方案。可以从我们的 EMQ 和Mongoose OS 条目一瞥当今物联网生态系统的主流功能,它们也例证了 物联网 的良好的发展状态。

象限亮点抢先看

要记住,就像适用于其他软件领域一样,封装也同样适应于事件和事件驱动的体系结构。特别是,我们需要考虑一个事件的范围,以及我们是否期望它在同一个应用程序、同一个领域或整个组织中被消费。DOMAIN-SCOPED EVENT将在其发布的同一个领域内被消费,因此我们期望消费者能够访问特定的上下文、资料或引用,进而对事件进行处理。如果这个事件的消费在组织内更广泛地发生,且事件的内容需要有所不同,我们就要注意不要“泄漏”其他依赖领域的实现细节。

身份管理是平台的关键组件之一。外部用户在使用移动应用的时候,需要对其身份进行验证,开发人员需要被授权才能访问基础设施组件,而微服务也需要向彼此证明自己的身份。你应该考虑的是,身份管理是否真的有必要自己来搭建和维护。根据我们的经验,HOSTED IDENTITY MANAGEMENT AS A SERVICE( SaaS)这种解决方案更为可取。我们相信,像Auth0和Okta这样的顶级托管商可以在“正常运行时间”和“安全”两方面提供更好的SLA。也就是说,虽然有时候自行搭建和维护身份管理解决方案是一个现实的选择,特别是对于那些有操作规范和资源的企业来说,这个选择更为安全。但大型企业的身份解决方案通常包含更广泛的功能,例如集中授权、治理报告和职责分离管理等等。不过,这些担忧通常与员工身份更相关,特别是那些受遗留系统限制的企业,尤其如此。

在实践微服务的过程中,为了将后端资源进行聚合,我们实践了一个又一个的模式。之前,我们经常使用类似于Netflix Falcor这样的工具帮助我们实现BFF(Backend for Frontend ),现在很多项目已经开始使用GRAPHQL FOR SERVER-SIDE RESOURCE AGGREGATION。GraphQL可以让客户端直接使用特定的查询语句去访问BFF以获取数据。使用这项技术时,后端服务可以继续暴露 RESTful API,而GraphQL可以轻易的将这些服务所提供的资源聚合在一起,并且对客户端十分友好。我们推荐GraphQL是因为其简化了BFF和其他聚合服务的实现。

在高度分布式的微服务架构中,其可观察性有一个两难问题 —— 要么记录一切,代价是巨量的存储空间;要么随机抽样记录,代价是有可能丢失某些重要事件。最近我们注意到一项技术,它在这两种方案之间提供了一个折衷方案。通过跟踪请求头中传入的某个参数来LOG LEVEL PER REQUEST。使用跟踪框架(可能基于OpenTracing标准),你可以在一次事务中的多个服务之间传递一个相关的ID。还可以在开始事务时注入其它数据(比如期望的日志级别),并且与跟踪信息一起传递它。这样可以确保这些额外数据在系统中总是和相应的单个用户事务一起流动。这在调试时也是个很有用的技巧,因为服务可能会暂停或以逐个事务的方式进行修改。

Headless CMS( Content Management Systems, 内容管理系统) 正在成为数字化平台的常见组件。CONTENTFUL是一个现代化的 headless CMS。我们的团队已经成功把它集成到开发工作流中。我们特别喜欢其“API 优先”的特点,及其CMS as Code的实现。它支持强大的内容建模原语代码和内容模型演化脚本,并允许将其视为其他数据存储的schema,并将演进式数据库设计实践应用到 CMS 开发中。我们所喜欢的其他特性包括:默认包含两个 CDN以提供多媒体资源和 JSON文档,本地化的良好支持和与Auth0集成的能力(尽管需要做出一些努力)。

EMQ是一个可伸缩的开源多平台 MQTT代理。为了追求高性能,它使用Erlang/OTP语言编写,能处理数百万的并行连接。它能支持多种协议,包括MQTT、MQTT传感器网络、CoAP以及WebSockets,使其适用于物联网和移动设备。我们已经开始在项目中使用 EMQ,很享受其安装以及使用的便捷性,以及它能将消息路由到不同目的地(包括Kafka和PostgreSQL)的能力,还有它在监控和配置上所采用API驱动的策略。

TICK STACK是一个由开源组件组成的平台。使用它就可以轻松地收集、存储、绘制基于时间序列的数据(如度量和事件)来触发告警。TICK Stack 的组件包括:收集和报告各种指标的服务器代理telegraf、高性能时间序列数据库InfluxDB、平台的用户界面 Chronnograf,以及可以处理来自 InfluxDB 数据库的流式数据和批量数据的数据处理引擎Kapacitor。不像基于“拉”模型的Prometheus,TICK Stack是基于“推”模型来收集数据的。InfluxDB 组件是该系统的核心,同时也是目前最好的时间序列数据库。虽然这套组件栈基于 InfluxData ,而且需要使用诸如数据库集群这样的 InfluxData 企业版的功能,但在监控方面它仍然是一个不错的选择。我们正在一些生产环境上使用该平台,并且获得了一些很好的体验。

WEB BLUETOOTH能够直接从浏览器控制任意低功耗蓝牙设备。这样以前只能通过原生手机应用来处理的场景,现在也可以适用了。该规范由 Web Bluetooth Community Group 发布,并且定义了一个 API,通过蓝牙 4.0 无线标准发现设备并在设备间通信。 当前,Chrome 是唯一支持这个规范的主流浏览器。借助Physical Web和 Web Bluetooth,现在有了其他途径来让用户与设备进行交互, 且无需让他们在手机上安装另一个应用。这是一个令人兴奋的领域, 值得密切关注。

我们很开心使用 BACKSTOPJS 来做 web 应用的可视化回归测试。作为可视化比较工具,它的可配置视窗和可调节容错能力可以很容易定位到细微差别。它有很优秀的脚本功能,并且可以选择在无界面Chrome、PhantomJS 和SlimerJS 中运行。我们还发现,它在实时组件样式规范的基础上运行时尤其有帮助。

世界上有数不清的问题都可以用数学优化问题来表达,而其中可以用凸问题来描述的那部分常常能够得到有效解决。CVXPY便是一种针对凸优化问题所开发的开源Python嵌入式建模语言。它由斯坦福大学的学者维护,已经为数个开源和商业解决方案提供了功能齐备的安装套件。它的文档中也包含了许多能够引起开发者使用兴趣的例子。尽管有些时候,我们仍然需要类似Gurobi和IBM CPLEX这类商业解决方案,但CVXPY在原型设计阶段可以说所向披靡。在多数情况下,有CVXPY就足够了。同时,基于最近的优化进展,其开发者一直在为我们提供更多的扩展包(例如DCCP)和相关软件(例如CVXOPT)。

HELM是Kubernetes的包管理器。共同定义某个应用的Kubernetes资源集合被打包成图表。这些图表可以描述单个资源,例如Redis pod,或者全栈的Web应用程序:HTTP服务器、数据库和缓存。Helm 默认带有一些精选的 Kubernetes应用,维护在官方的图表仓库里。想要为内部用途搭建私有的图表仓库也很容易。Helm有两个组件:一个是称为Helm的命令行工具,另一个是称为Tiller的集群组件。保护Kubernetes集群是一个宽泛而微妙的话题,但我们强烈建议在基于角色的访问控制(RBAC)环境中搭建Tiller。我们在很多客户的项目中使用了Helm,它的依赖管理、模板和钩子机制极大地简化了Kubernetes中应用程序的生命周期管理。

ARCHUNIT是用来检查架构特征的Java测试库,比如包与类的依赖关系、注解验证、甚至层级一致性。它可以在你现有的测试方案中,以单元测试的方式运行,但目前只能用于Java架构。ArchUnit测试套件可以合并到C(I 持续集成)环境或部署流水线,使我们很容易地以演进式架构的方式实现适应度函数。

Hyperledger项目现在已经发展成包含一系列子项目的大工程。针对不同业务需求,可以支持不同的区块链实现方式。例如,Burrow专门用来实现带权限控制的Ethereum,而Indy更专注于数字身份。在这些子项目中,Fabric是最成熟的一个。当开发者们谈到使用 Hyperledger 技术时,实际上大多数时候是在考虑 Hyperledger Fabric。然而,chaincode的编程抽象相对底层,因为它直接处理账本的状态数据。此外,在编写第一行区块链代码之前,搭建基础设施也经常耗去很多时间。HYPERLEDGER COMPOSER 构建于Fabric基础之上,加速了将想法实现为软件的过程。Composer 提供 DSLs 来建立业务资源模型、定义访问控制和构建业务网络。使用 Composer,可以在不搭建任何基础设施的情况下,仅通过浏览器来验证我们的想法。需要明确的是,Composer 本身并不是区块链,仍然需要把它部署在 Fabric 上。

RASA是聊天机器人领域的新成员。 它并非使用简单的决策树,而是通过神经网络将用户意图和内部状态映射到回应上。Rasa 集成了自然语言处理解决方案(spaCy)。与技术雷达中的其他同类工具不同,Rasa是开源软件,可以自行托管,对于担心数据所有权的使用者来说 Rasa 是一个可行的方案。我们在内部应用中使用了Rasa Stack,效果良好。

RIBs即路由器(Router)、交互器(Interactor)和构建器(Builder)的缩写, 是来自 Uber 的跨平台移动架构框架。RIBs的核心思想是将业务逻辑从视图树中分离出来,从而确保应用程序由业务逻辑驱动。 可以将其看作是Clean Architecture模式在移动应用程序开发领域的一次应用。通过在原生 Android 和 iOS 应用上使用一致的架构模式,RIBs为应用提供了清晰的状态管理模式和良好的可测试性。尽管我们一直建议尽量将业务逻辑放在后端服务,不要将其泄漏到前端视图中,但移动应用程序非常复杂,RIBs可以帮助管理这种复杂性。

REACTOR是一个基于Reactive Streams规范的、用于开发非阻塞式应用程序的 JVM 库,支持 JVM 8 及以上版本。响应式编程强调将命令式逻辑转换成异步、非阻塞和函数式风格的代码,特别是在处理外部资源时。Reactor 实现了 Reactive Streams 规范,并且提供了两个不同的发布者API:Flux (0 到 N 个元素) 和 Mono( 0 或 1 个元素),可以高效地对基于推送的流处理进行建模。Reactor 项目非常适合微服务架构,并且为HTTP、WebSockets、TCP和UDP等提供了支持背压(backpressure)的网络引擎。

以上是我们在最新一卷技术雷达中随机摘取的几个Blips,欲获取整版技术雷达,请点击这里

Share