2017年11月期技术雷达正式发布!

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

技术雷达的内容来自于 ThoughtWorks 的观察、对话以及在应对最令客户棘手的业务挑战时所沉淀下的一线经验,其中既包含现有技术,也包含新兴技术。技术雷达报告使用可视化的方式将技术趋势分为四组,分别涵盖技术、平台、工具和语言与框架,每个领域又进一步细分为暂缓、评估、试验或采用。


本期四大主题

崛起的中国开源软件市场

星星之火,已成燎原之势!在态度和政策发生转变之后,包括阿里巴巴和百度在内的众多大型中国企业正在积极发布开源框架、工具和平台。中国软件生态正伴随着经济扩张而加速成长。从这个巨大而繁荣的软件市场向 GitHub 等开源网站发布的开源项目的数量必将持续增多,质量也将持续提高。中国企业为何热衷于将他们的众多资产开源出来?与硅谷等其他活跃的软件市场一样,各个企业对开发人员的争夺十分激烈。紧紧提升薪酬水平是不够的,让聪明的开发者一起在最前沿的开源软件上共事才能够持续激励他们,这是一个放之四海而皆准的通则。我们预期主要的开源创意会继续保持 README 文件中先有中文版后有英文版的趋势。

容器编排首选Kubernetes

Kubernetes 及其在许多项目中逐渐增强的主导性推动了大量雷达条目的更新,以及更多的讨论。似乎软件开发生态系统正在 Kubernetes 及其相关工具的周边稳定发展,以解决有关部署、规模化和容器操作这些常见问题。诸如 GKE,Kops 和 Sonobuoy 这些雷达条目提供了托管平台服务和工具,以改善采用和运行 Kubernetes 的整体体验。事实上,它具备用一个调度单元来运行多个容器的能力,可以让服务网格(service mesh)和能够实现端点安全的 sidecar 得以实现。 Kubernetes已经成为容器的默认操作系统——许多云提供商已经利用其开放的模块化架构来采用和运行Kubernetes,而它的工具则可以利用其自身开放的API来访问诸如负载、集群、配置和存储等功能。我们看到更多的产品正在把Kubernetes作为一个生态系统来使用,使其成为继微服务和容器之后的下一个抽象层次。更多迹象表明,尽管面临分布式系统固有的复杂性,开发人员仍然可以成功地驾驭现代的架构风格。

成为新常态的云技术

本期技术雷达讨论中的另一个普遍性话题,无疑是近期的“多云”天气。 随着云提供商的技术能力越来越强大,且可以提供同样好用的功能,公有云正在成为许多组织中新的默认选择。当启动新项目时,许多公司已经不再问“为什么放在云端?”,而是问“为什么不放在云端?”。 诚然,某些类型的软件仍然要在公司内部私有地部署,但随着价格的下降和功能的扩展,云原生(cloud-native)开发的可行性越来越高。尽管主要的云解决方案提供商提供的基本功能都很相似,但它们也都提供了一些独特的产品特性,以针对特定类型的解决方案来实现差异化。因此,我们看到一些公司通过“多云”(Polycloud)策略来同时使用几个不同的云提供商,从中分别挑选最能满足其客户需求的平台专业能力。

各方对区块链的信任稳步增强

尽管加密货币市场仍然处于混沌状态,我们的许多客户已经开始尝试利用基于区块链的解决方案来处理分布式账本和智能合约的需求。雷达中的一些条目展示了区块链相关技术运用的成熟度,它们使用各种新技术和编程语言并以一些有趣的方式来实现智能合约。区块链解决了“分布式信任”与“共享且不可篡改的账本”这些老大难问题。如今,许多公司正致力于增强其用户对将区块链作为系统的底层实现机制的信心。许多行业存在着明显的“分布式信任”问题,我们期待区块链技术能持续找出解决这些问题的方法。


部分亮点预览

技术篇:

DesignOps:受DevOps运动的启发,包含一系列实践和文化转变的DesignOps横空出世。它可以帮助组织不断重新设计产品,而不在质量、服务一致性和团队的自主性上妥协。 DesignOps提倡创建并不断演进设计的基础,最大限度降低创造新的UI概念及其变体的工作量,并与最终用户建立快速可靠的反馈机制。使用DesignOps,设计正在从一种具体的实践演变成每个人工作内容的一部分。

Chaos Engineering:在早期的技术雷达中,我们讨论了Netflix的Chaos Monkey。Chaos Monkey可以随机终止生产系统中的运行实例,并对结果进行度量,从而帮助验证系统在运行时对生产中断的应对能力。今天,人们有了一个新兴术语来描述这一技术的广泛应用:混沌工程。在生产环境的分布式系统中运行这些实验,可以帮助我们建立系统在动荡环境下依旧能够按预期工作的信心。如果想要更好地理解这个技术方向,请参阅混沌工程原理。

Service Mesh:现在越来越多的大型组织在向更加自组织的团队结构转型,这些团队拥有并运营自己的微服务,但他们如何在不依赖集中式托管的基础架构下,确保服务之间必要的一致性与兼容性呢?为了确保服务之间的有效协作,即使是自组织的微服务也需要与一些组织标准对齐。服务啮合在服务发现、安全、跟踪、监控与故障处理方面提供了一致性,且不需要像API网关或ESB这样的共享资产。服务啮合的一个典型实现包含轻量级反向代理进程,这些进程可能伴随每个服务进程一起被部署在单独的容器中。反向代理会和服务注册表、身份提供者和日志聚合器等进行通信。通过该代理的共享实现(而非共享的运行时实例),我们可以获得服务的互操作性和可观测性。一段时间以来,我们一直主张去中心化的微服务管理方法,也很高兴看到服务啮合这种一致性模式的出现。随着 linkerd 和 Istio 等开源项目的成熟,服务啮合的实现将更加容易。

平台篇:

TensorFlow Serving:机器学习模型已经开始渗入到日常的商业应用中。 当有足够的训练数据可用时,这些算法可以解决那些以前可能需要复杂的统计模型或试探法的问题。 随着机器学习从试验性使用转向生产环境,需要一种可靠的方式来托管和部署这些可远程访问的模型,并能随着消费者数量的增加而进行扩展。TensorFlow Serving 通过将远程gRPC接口暴露给一个被导出来的模型,解决了上述部分问题。这允许以多种方式部署训练完成的模型。TensorFlow Serving 也接受一系列的模型来整合持续的训练更新。其作者维护了一个Dockerfile来简化部署过程。 据推测,gRPC 的选择应与 TensorFlow 执行模型保持一致。 但是,我们通常都会对需要代码生成和本地绑定的协议保持警惕。

LoRaWAN:LoRaWAN是一种低功耗广域网,专为低功耗、远距离和低比特率的通信场景而设计。它提供了边缘设备与网关设备之间的通信能力,能够通过后者将数据转发至应用程序或者后台服务。LoRaWAN通常用于分布式传感器组或物联网这些必须具备长电池寿命和远距离通信能力特点的设备上。它解决了在使用一般的WiFi进行低功耗广域网通信时的两个关键问题:通信距离和功耗。LoRaWAN已有若干实现,其中值得注意的是一个免费的开源实现——The Things Network。

Language Server Protocol:那些大型 IDE 的威力很大程度上源于利用源代码分析出的抽象语法树(AST)来进一步分析和操作源代码的能力,比如代码补全,调用分析和重构。语言服务器将这种能力提取到单独的进程中,从而让任意文本编辑器都可以通过 API 来使用 AST。微软从他们的 OmniSharp 和 TypeScript 服务器项目中,提炼并引领了”语言服务器协议”(Language Server Protocol, LSP)的拟定。编辑器只要使用 LSP 协议就可用于任何具备 LSP 兼容服务器的编程语言。这意味着我们可以继续使用自己喜爱的编辑器,同时也不必放弃各种编程语言的高级编辑功能——这对于很多 Emacs 瘾君子来说尤其利好。

工具篇:

Gopass:gopass是一个基于GPG和Git的团队密码管理解决方案。它的前身是pass,并在此基础上增加了诸如多用户密码管理、层级式密码存储、交互式查找、基于时间的一次性密码(TOTP),以及二进制存储格式等功能。由于它的存储格式与pass基本兼容,因此可以直接从pass迁移过来。这意味着只需调用一次存储密钥就能将其集成到迁移的整备工作流中。

Jupyter:过去几年间,我们注意到分析笔记本应用(analytics notebooks)的流行度在持续上升。这些应用都是从 Mathematica 应用中获得灵感,能够将文本、数据可视化和代码活灵活现地融入到一个具备计算能力的文档中。在上个版本的技术雷达中我们所提到的基于Clojure 的GorillaREPL,就属于此类工具。但随着人们对机器学习的兴趣不断增加,以及该领域中的从业者们逐渐将Python作为首选编程语言,大家开始集中关注Python分析笔记本了。其中 Jupyter 看起来在ThougthWorks团队中格外引入注目。

Rendertron:JavaScript Web 富应用的一个老问题是如何使这些页面的动态渲染部分可供搜索引擎检索。为此开发人员采用了各种各样的技巧,包括使用 React.js 的服务端渲染,外部服务或预渲染内容。现在谷歌 Chrome 新的 headless 模式又贡献了一个新的技巧—— Rendertron,即 Chrome的headless 渲染解决方案。它在一个 Docker 容器中封装了一个 headless 的 Chrome 实例,可以作为独立的HTTP服务器来部署。无法渲染JavaScript的爬虫机器人可以被路由到此服务器来进行渲染。 虽然开发人员也可以部署自己的 headless Chrome代理并配置相关的路由机制,但 Rendertron 简化了配置和部署过程,并提供了令爬虫机器人进行检测和路由的中间件示例代码。

语言&框架:

Gobot:Go语言能够被编译为裸片上运行的目标程序,这使得嵌入式系统开发领域对它的兴趣与日俱增 。GoBot是一个用于机器人、物理计算和物联网(IoT)的框架,它基于Go语言编写,并且支持多个平台。我们在一个对实时性响应没有要求的实验性机器人项目中使用了GoBot,并且用GoBot创建了开源的软件驱动。GoBot的HTTP API使其与移动设备的集成十分容易,从而能创建更丰富的应用。

Solidity:智能合约编程需要一种比交易处理脚本更具表现力的语言。在众多为智能合约设计的新编程语言中,Solidity是最受欢迎的。这是一种面向合约的静态类型语言,其语法类似于JavaScript。 它抽象了智能合约中自我实现的业务逻辑。围绕Solidity的工具链也在快速成长。如今,Solidity是Ethereum平台的首选编程语言。

CSS-in-JS:CSS-in-JS是一种用JavaScript编写CSS样式的技术,通过鼓励采用一种通用模式,编写样式以及应用样式的JavaScript组件,使样式和逻辑的关注点得到统一。该领域中的新秀——诸如JSS,emotion和styled-components,依靠工具来将CSS-in-JS代码转化成独立的CSS样式表,从而适合在浏览器里运行。这是在JavaScript中编写CSS的第二代方法,与以前的方法不同,它不依赖于内联样式,这意味着它能支持所有CSS特性,使用npm生态共享CSS以及跨平台使用组件。我们的团队发现styled-components很适合像React.js这样基于组件的框架,并且可以使用jest-styled-components做CSS的单元测试。这是个新兴的领域且变化迅速。用该方法时,在浏览器里人工调试生成的class名称会需要费些功夫,并且可能不适用于那些前端架构不支持重用组件并需要全局样式的项目。

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

Share

DevOps发展的9个趋势

DevOps包含了太多方面的技术和实践,很难通过一个统一的工具链来描述其发展。即便如此,我们仍然可以从ThoughtWorks技术雷达的条目变动中看出一些趋势。今年,我有幸作为主编参与了最新一期技术雷达的译制,作为DevOps的爱好者,十分高兴能在这一过程中看到DevOps未来发展的几个趋势,总结成了这篇文章。

趋势1:微服务目前仍然是DevOps技术应用和发展的主要领域

微服务将单块应用系统切割为多个简单独立的应用。从技术上说,这是通过工具把应用程序的内部复杂度转化为外部复杂度,需要一系列工具支撑微服务本身以及服务之间的通信。从组织上说,微服务团队要满足“快速发布,独立部署”的能力,则必须具备DevOps的工作方式。

如何拆解微服务一直是微服务技术应用的最大难点之一,领域驱动设计是比较理想的微服务拆解方法论。社会化代码分析帮助团队通过更精确的数据找到更加合适的拆分点。CodeScene是一个在线服务,它能帮助识别出热点和复杂且难以维护的子系统,通过分析分布式子系统在时间上的耦合发现子系统之间的耦合。此外,它还能帮你认识组织中的康威定律,这会大大降低微服务解耦的难度。

此外,微服务系统本质上是一个分布式系统,分布式系统之间的通信一直是很重要的问题。本期介绍的Kafka StreamsOpenTracing就是这类技术的条目。Kafka作为一个成熟的分布式消息系统已经被广泛采用,而Kafka Streams则将最佳实践以“库”的方式呈现给开发人员,使得操作Kafka更加自然和简单。而OpenTracing则弥补了跨越多个微服务之间请求追踪的空白。

另一方面,无服务器风格的架构(Serverless architecture)把DevOps技术在微服务领域的应用推向极致。当应用程序执行环境的管理被新的编程模型和平台取代后,团队的交付生产率得到了进一步的提升。一方面它免去了很多环境管理的工作,包括设备、网络、主机以及对应的软件和配置工作,使得软件运行时环境更加稳定。另一方面,它大大降低了团队采用DevOps的技术门槛。

然而,端到端交付以及微服务中的函数管理问题日渐突出。尽管AWS API gatewayAWS Lambda几乎成了Serverless架构的代名词,但这二者结合的开发者体验并不佳。于是出现了Serverless frameworkCLAUDIA这样的管理工具。

AWS Lambda带来的优势也深深影响了企业级应用领域,Apache OpenWhisk就是企业级无服务器领域的选择之一,它使得企业级应用也可以采用无服务器风格的架构构建应用程序。

在微服务端到端交付流程上,Netflix开源了自家的Spinnaker,Netflix作为微服务实践的先锋,不断推出新的开源工具来弥补社区中微服务技术和最佳实践的缺失。而Spring Cloud则为开发者提供了一系列工具,以便他们在所熟悉的Spring技术栈下使用这些服务协调技术(coordination techniques),如服务发现、负载均衡、熔断和健康检查。

而在微服务的安全上,最常见的需求之一 是通过身份验证和授权功能来保护服务或API。这部分功能往往是最重要且不断重复构造的。而Keycloak就是一个开源的身份和访问管理解决方案,用于确保应用程序或微服务的安全。且几乎不需要编写代码,开箱即用。它支持单点登录,社交网络登录和标准协议登录(如OpenID Connect,OAuth2和SAML等)。

趋势2:以Docker为核心的数据中心方案逐渐走向成熟

在过去的两年,Docker社区有了突飞猛进的发展,似乎每期技术雷达都会出现Docker相关的条目。而Docker往往和DevOps联系起来,被认为是推动DevOps发展的杀手级工具,以至于有些人会以团队是否采用Docker作为团队是否具备DevOps能力的标志。

而这一社区的创新数量则日渐平缓。一方面,开源社区激烈的竞争淘汰了一部分技术。另一方面,以Docker为中心的完整数据中心解决方案在不断的整合开源社区的零散工具并形成最佳实践。为端到端的开发和运维提供更完整的交付体验,各大厂商也相继开始推广自己的企业级整体收费解决方案,这表明Docker的使用已经走向成熟。

​在本期的技术雷达里的条目中出现了Mesosphere DC/OS,这是构建统一技术栈数据中心的一个征兆。在这方面Docker EERancher都是非常有力的竞争者。根据我的判断,在未来的Docker社区里,统一容器化数据中心的竞争者将会进一步减少。而之前的私有云方案则慢慢会被“以Docker为核心数据中心级全栈交付”取代。

趋势3:不完整的DevOps实践阻碍着DevOps的发展

很遗憾看到单一持续集成实例不完整的持续集成(CI Theatre)这样的条目出现在技术雷达里。可以感到企业应用DevOps技术的紧迫性。这同时也暴露了DevOps领域里“缺乏门槛较低且成熟的技术实践”的问题。

大部分企业在DevOps转型中仅仅关注到了工具的升级。却忽视了价值流、生产流程中各个活动中的最佳实践以及DevOps团队文化的构建,这会使团队陷入“已经完成DevOps转型的假象“,而停止了团队的自我改进。

DevOps的实践包含组织改进和技术升级两个部分,技术往往是最容易的部分。而缺乏组织改进的技术提升往往很难给组织带来质的飞跃。具备DevOps文化的团队则会不断反思和学习,通过共担责任和相互合作不断完善组织的DevOps实践。

趋势4:领域特定的DevOps实践开始出现

DevOps的最早实践来自于互联网企业的Web应用,相应的思想被引入企业级应用并促进了一系列工具的发展。虽然并不是每一种应用软件交付形式都适合DevOps,但随着DevOps的工具不断成熟。其它领域的DevOps实践也开始尝试借鉴Web应用领域的自动化工具,并逐渐形成领域级的DevOps实践。

在人工智能领域,TensorFlow就是这样一个例子,它可以有多种DevOps友好的安装和部署方式 ,例如采用Docker进行部署。

在区块链领域,超级账本(HYPERLEDGER) 就是这样一个例子,它提供了一套工具和服务,结合DevOps相关技术和实践形成了一个完整的解决方案。

随着DevOps相关概念和技术不断向各个产业领域的深入发展,可以看到DevOps技术和实践带来的巨大影响力。然而,每个技术领域都有自己所关注的特性,并不是以往的DevOps实践可以全覆盖到的,这恰恰成为了DevOps技术和实践发展的契机。我很期待领域特定的DevOps技术实践给DevOps带来的发展。

趋势5:采用DevOps进行技术债务重组和技术资产管理

技术债务类似于金融债务,它也会产生利息,这里的利息其实就是指由于鲁莽的设计决策导致需要在未来的开发中付出更多的努力。

投资银行业往往采用多种金融工具组合的方式来处理企业的不良债务。而清理技术债务的实践和工具却乏善可陈。

技术债务不光阻碍了企业通过新技术带来便利,还使企业偿还技术债务所承担的成本越来越高,例如技术人才的流失,技术利息等综合性风险。

虽然极少会出现企业因技术债务而走向衰败的案例,但新晋企业凭借新技术和商业模式颠覆传统行业并夺取市场份额的报道却不断发生。 这从另一方面说明技术债务综合提升了采用新技术的机会成本,使企业不断失去创新和领先的巨大潜力。

DevOps技术栈的多元化为分散遗留系统技术债务风险提供了一套灵活而又低风险的工具和方法论。不断帮助企业从遗留系统的负担中解脱出来。

而微服务则是首先通过领域拆分技术债,并用相应工具重组技术债。分离优质技术资产和不良资产,通过分散风险来降低抛弃成本。 而将API当做产品(APIs as a product)可以从一个全新的演进视角去看待技术债,通过可用性测试和用户体验研究帮企业剥离出技术债务中的优质资产和不良资产。

另一方面,本期技术雷达中出现了封装遗留系统这样的实践,它往往配合着Vagrant,Packer和Docker这样的工具一起使用。一方面它将技术债务的风险进行了隔离,另一方面它防止了遗留系统上产生的技术债利息的增长。

趋势6:安全成为推动DevOps全面发展的重要力量

安全是DevOps永远绕不开的话题,也往往是新技术在传统行业(例如金融和电信)应用中的最大阻碍。一方面,组织结构的转型迫使企业要打破原先的部门墙,这意味着很多原先的控制流程不再适用。另一方面,由于大量的DevOps技术来源于开源社区,缺乏强大技术实力的企业在应用相关技术时不免会有所担忧。

从代码中解耦秘密信息的管理则让我们避开了一些开发过程中可能会产生的安全隐患。采用git-crypt这样的工具可以帮我们保证在开发的过程中源代码内部的信息安全。而采用HashiCorp Vault则提供了脱离应用程序代码的秘密信息存储机制,使得应用在运行过程中的秘密得到了有效保护。

Linux Security Module则一直在技术雷达的“采用”区域,通过SELinux和AppArmor这样的LSM兼容帮助团队评估谁可以访问共享主机上的哪些资源(包括其中 的服务)。这种保守的访问管理方法将帮助团队在其SDLC流程中建立更好的安全性。以往这是Ops团队需要考虑的问题,而对DevOps的团队来说,这是每一个人的事情。

“合规性即代码”(Compliance as Code)是继“基础设施即代码”,“流水线即代码”之后的又一种自动化尝试。InSpec作为合规性即代码的提出者和实现者,通过自动化手段确保服务器在部署后的运维生命周期中依然保持安全与合规。它所带来的意义在于将规范制度代码化,得到了确定性的结果和解释。

在不远的将来,不难想象人们所面对的法律和法规规定不再是一堆会导致歧义的语言文字条目,而是一组由自动化测试构成的测试环境。

安全性和易用性往往被认为是鱼与熊掌不可兼得的两个方面。在DevOps之前,团队吞吐量和系统稳定性指标曾经也面临这样的境遇,然而DevOps使得二者可以兼得。同样我也有信心看到在未来DevOps的领域里,更多易用且安全的工具将会不断出现。在降低DevOps所带来的安全风险的同时,也提升团队开发过程的顺畅性和用户便利性。

趋势7:Windows Server和.NET平台下的DevOps技术潜力巨大

长期以来,Windows和.NET平台下的DevOps一直都是一个被低估的领域。一方面,社区缺乏对 Windows Server平台的兴趣。另一方面,Windows Server却有接近90%的市场占用率,在Web服务器领域则有33.5%的市场占有率

有充足理由证明这是一个潜力巨大的市场。 我们看到了CAKE和FAKE这样的条目,作为.NET平台下替代MSBuild的构建解决方案, 它增强了.NET平台自动化方面的能力。而HANGFIRE则提供了更易用和灵活的自动化进程调度框架。我很期待未来有更多Windows Server和.NET平台领域的创新。不久前,Docker已经可以在Windows下运行。可以预见到,Windows Server和.NET平台将会是下一阶段DevOps技术实践中值得深入发掘的领域。

趋势8:非功能性自动化测试工具的逐渐完备

自动化测试水平往往是衡量DevOps技术能力高低的重要指标,尤其是针对生产环境应用程序的非功能性自动化测试工具。一直以来,技术雷达都在尝试从不同的角度宣扬自动化测试的重要性,从软件的开发阶段延展到了整个应用生命周期甚至整体IT资产的管理上。

这期的技术雷达仍然关注了非功能性自动化测试,TestInfra是ServerSpec的Python实现,它使得用Pytest测试基础设施成为可能。而MOLECULE旨在帮助开发和测试Ansible的Role 。通过在虚拟机或容器上为正在运行的Ansible Role测试构建脚手架,无需再手工创建这些测试环境。正如技术雷达所说的:“虽然这是一个相当年轻的项目,但我们看到了其蕴含的巨大潜力。”

趋势9:Python成为DevOps工作中所不可或缺的语言

早在DevOps刚刚开始盛行的时候,Python就是一个被寄予厚望的语言,因为大部分DevOps工具和实践都需要用到Python。虽然也有人尝试用Ruby或者NodeJS构建DevOps工具,然而都没有Python所构建的工具流行。与此同时,仍然不断有人把其它语言下编写的工具转化为Python的版本,TestInfra就是这样一个例子。

随着Python在大数据、人工智能、区块链、微服务以及Docker中的发展,可以预见Python在日后的领域仍然会发挥重要的作用。

以上对DevOps趋势的解读仅为个人观点,如有不当之处还望指出。关于更多技术在技术雷达中的使用建议请参考这里,谢谢。


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

Share

技术雷达之微服务架构

最近几年,微服务架构异军突起,与容器技术相辅相成,成为架构设计领域热议的话题。而《技术雷达》作为ThoughtWorks出品的一份关于技术趋势的报告,在技术社区也一直有着非常好的口碑。本篇文章就试图结合技术雷达与微服务架构,以往期技术雷达中微服务架构的演变来审视一下这个新兴架构的整个发展过程。

相信大家了解微服务架构或者听说微服务架构也都是近两年的事情,从Google Trends的搜索数据统计上看,微服务架构确实也是从2014年才逐渐兴起,到目前呈现出一个爆发的趋势。

但技术雷达在2012年的3月份就已经提及了微服务架构相关的内容,在当时,其所处的状态还是评估(Assess)阶段,这就说明技术雷达早在2012年初的时候就已经成功捕获到微服务架构这个新的技术架构。

(微服务2012年第一次出现在技术雷达上)

到底什么才是微服务架构,Martin Fowler在那篇著名的描述微服务架构的文章中第一次定义了微服务架构并阐述了其九大特性。而我一开始接触微服务架构的时候也觉得这好像不是一个新的概念,很早之前就有RPC和SOA这种面向服务的分布式架构,又冒出一个新的微服务架构,他们到底有什么区别?

看到Martin Fowler的定义以后,才慢慢清楚他们的区别,在Martin Fowler的定义中有几个关键字可以让我们甄别一个分布式架构是传统的面向服务架构还是新的微服务架构:每个服务是不是跑在独立的进程中?是不是采用轻量级的通讯机制?是不是可以做到独立的部署?

(微服务架构的定义)

时间来到了2012年的10月份,在这期的技术雷达中,微服务架构已经从评估(Assess)阶段被移到实验(Trial)阶段。什么叫实验阶段?ThoughtWorks内部有一个解释,就是这项技术已经可以运用在实际项目中,但你仍要控制风险,也就是说此项技术已经可以在风险比较低的项目中使用了。

一个项目要能被移到试验的阶段,还有一个必须要满足的条件,就是必须在ThoughtWorks自己的项目中已经开始实际使用。幸运的是,我当时所在的项目也是在2012年10月份左右开始采用微服务架构的,结果也是非常好的。我们在3个月完成一个新的应用并成功上线,当时客户评价很高。

实际体验下来,微服务架构对我们究竟有哪些好处?这几点是我体会到的:

首先是组件化,作为一个软件开发人员,我们一直都有一个梦想,就是希望有朝一日可以把一堆组件像乐高一样通过直接拼装的方式快速构建我们的应用。无论是最早基于拖拽的方式构建应用,还是现在大热的前端组件化,我们一直都在试图寻找一种更好的组件化方式,微服务架构也是其中之一。但构建软件本身仍是一个非常复杂的过程,微服务架构为我们提供了一种组件化的可能,但直到现在还不好说它能不能达到我们作为整体组件化的目标,但是至少从实际体验来看,它确实能给我们带来组件化的很多好处。

然后是弹性架构,在2015年11月期技术雷达中推荐了亚马逊的弹性计算平台,如果我们的系统是由按业务划分的服务构成,结合容器技术和云平台我们就可以构建一个极具弹性的架构。通过云平台实时的监控,一旦发现资源紧张,立刻就可以通过云平台和容器技术自动瞬间扩展出成百上千的服务资源,在高峰过去之后又可以立即把所有的服务注销掉,释放资源,整个过程完全是自动化的。

去中心化和快速响应也是微服务架构给我们带来的好处。在单体架构下,会非常依赖于项目一开始时对于技术选择,一旦选择了一个技术栈,那么之后几年都被绑定在了这样一个技术栈下,很难应对变化。微服务架构则给我们提供了一个更细粒度使用技术的可能,在不同的服务里可以使用完全不同的技术栈,不同的语言、框架甚至数据库,真正做到用最适合的技术解决最适合的问题,从而让我们可以更加敏捷地响应需求和市场的变化,增加了竞争力。

(微服务架构的好处)

从2012年10月份一直到2014年的7月份,在这个时间段有大量与微服务架构相关的工具、技术和框架出现在技术雷达上。包含了很多领域:语言、测试,框架、CI、CD、持续交付,安全等等。

从2012年的3月份微服务架构第一次出现在技术雷达上一直到2014年7月份,虽然微服务架构已经有了比较大的发展,技术雷达上也已经推荐了大量相关的内容,但在当时社区中谈论微服务架构的声音并不多,这也体现出了技术雷达的前瞻性。

(技术雷达上微服务架构相关项目)

从2014年7月份开始微服务在社区就开始呈现出一种爆发的趋势,但在紧接着的2015年1月刊的技术雷达中却出现一个非常有意思的项目:Microservice Envy。通俗点儿讲就是“微服务红眼病”,或者说是“微服务你有我也要”。

这意味着在社区刚刚爆发,对于微服务架构踩下油门的时候,我们已经踩下了一脚刹车。但这并不是代表我们不看好微服务架构,而是认为需要认真思考我们是否真正需要以及何时以何种方式使用微服务架构,不能看别的人都在使用也盲目切换到微服务架构下。

这是因为微服务架构并不是免费的午餐,使用微服务架构是需要门槛和成本的。我们需要问自己:用微服务我们够“个”吗?或是说用微服务我们够“格”么?我们是否有这个能力和足够的资源驾驭这个新的架构?

Martin Fowler在他的《企业应用架构模式》中,就提到了分布式对象设计的第一原则:“设计分布式对象的第一个原则就是不要使用分布式对象”。因为分布式系统会给我们带来很大的挑战,让系统复杂度大幅增加的同时,我们还需要面对开发环境、测试、部署、运维、监控,一致性和事务等一系列的问题。

(Microservice Envy)

所以说,微服务架构虽然看起来非常美好,但是也是有很大附加成本的。通过下面这张图可以看到,横轴是时间轴,纵轴是生产力。当软件的复杂度很低的时候,单体架构下的生产力是要高于微服务架构的,但随着复杂度的不断增加,无论是单体应用还是微服务应用的生产力都会下降,只是微服务架构的下降会相对缓慢一些。

这也容易理解,因为在微服务架构中,我们的系统是由很多的小的服务组成,每一个服务都很小,相对简单,技术栈也很独立。这样做局部的变更也会更加容易,随着系统复杂度的不断增加,微服务的优势也就慢慢地体现出来了。

那要如何应对呢?为了追求生产力的最大化,一开始我们可以选择从一个单体架构开始,然后争取在微服务架构生产力超越单体架构的那个复杂度点切换到微服务架构上来,这样才能实现生产力的最大化。这就是Martin Fowler提出的单体应用优先原则(MonolithFirst),以单体架构开始,通过演进式设计逐渐重构到微服务架构。

(MonolithFirst)

为了保证从单体架构演进到微服务架构的重构过程安全可控,还需要有一套良好的质量守护机制。下图描述的就是Martin Fowler提出的微服务架构下的测试策略,我所在项目就是按照这种方式来划分和设计我们各种不同类型的测试,帮助我们在对于服务的抽取合并分离的重构过程中做到安全可控。

(Testing Strategies in a Microservice Architecture)

我们刚才提到了康威定律,康威定律说的是设计系统的组织产生的设计和架构等价于组织间的沟通结构。而康威定律还有一个逆定律:如果想改变一个设计架构方式,首先要改变组织结构。我们经常发现推动技术架构的转型和演进很难,因为我们在调整技术架构的同时却忽略了组织结构也要对应做相应的调整以匹配技术架构的变化,当组织结构与技术架构不匹配的时候,就会相互拉扯,这些都是在当时的技术雷达中着重强调的。

截至目前,以上内容都还是在谈论2015年以前各期技术雷达里的内容。在这之后直到现在,技术雷达也还在持续地推荐微服务架构相关的内容。所以说踩下刹车并不是因为我们走错了路,只是走的太快了,需要时刻提醒自己不要盲目,要清楚微服务给我们带来了什么和有着什么样的挑战,最终解决我们的问题。

来到最新的几期技术雷达,微服务架构还在不断的演进,而且慢慢的与其他新兴的技术融合形成一整套的新的不同以往的构建软件的解决方案。例如无服务器架构、对Docker的应用、对PaaS各种云的应用等,这些技术的发展,会不会对微服务架构的演进提供更多可能?是否可以为微服务架构早一天落地、改变我们的开发方式提供可能?让我们大家一起拭目以待。


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

Share