认识达内从这里开始

随着科学技术的不断突破，越来越多的技术被程序员和设计师所掌握，今天我们就一起来了解一下在技术与平台上都有哪些技术。

一、技术

轻量级架构决策记录

很多文档都可以被高度可读的代码和测试取代。然而，对于演进式架构来说，记录某些设计决策非常重要，这不仅有利于未来的团队成员理解，也有利于外部监督。轻量级架构决策记录是一种用于捕获重要的架构决策及其上下文和结果的技术。我们建议将这些详细信息进行版本化，而不是wiki或网站，这样所记录的内容就可以和代码保持同步。对于大多数项目，我们没有理由不采用这种技术。

将产品管理思维应用于内部平台

过去12个月里，我们注意到对数字化平台这个主题的关注发生了急剧的增长。希望快速有效推出新数字解决方案的公司，正在建立内部平台，为交付团队提供自助服务，从而访问那些构建和运营自己的解决方案所必需的业务API、工具、知识和支持。我们发现，当这些平台得到跟外部产品同等的重视时，它们的效率是最高的。将产品管理思维应用于内部平台，意味着与内部消费者(开发人员)建立共情，并在设计上彼此协作。平台的产品经理要建立路线图，确保平台为业务交付价值，为开发者改善体验。一些企业甚至为内部平台创建了品牌标识，并向同事推销平台的优势。平台产品经理将负责平台的质量、收集使用指标，并持续改进平台。将平台作为产品来处理，有助于创造一个蓬勃发展的生态系统，避免构建另一个停滞不前的、未充分利用的面向服务架构。

DesignOps

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

混沌工程

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

无服务器架构

无服务器架构迅速得到了需要部署云端应用的组织的认可，并且有着大量可供选择的部署方式。即便是相对传统和保守的组织，也在使用一部分无服务器技术。虽然可以使用的合适的模式仍在不断涌现，但大多数时候我们的讨论都会走向函数即服务(FunctionsasaService)(例如AWSLambda，GoogleCloudFunctions，AzureFunctions)。部署无服务器函数毫无疑问能够减少大量传统方式特有的，涉及服务器和操作系统配置和编排的工作量。然而serverless也并不是百试不爽的万金油。当前这个阶段，因为一些特别的需求，你必须做好能回退至容器化，甚至是实例化部署的准备。与此同时，无服务器架构的其他组件，比如后端即服务(BackendasaService)，几乎成为了默认的选择。

ServiceMesh

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

二、平台

Kubernetes

自我们上次在技术雷达中提到Kubernetes至今，它已经成为我们大部分客户将容器部署到服务器集群的默认解决方案。而能替代它的其他产品不但没有获得如此的客户认同度，甚至在某些场景中，我们的客户会将他们的“引擎”都更换成Kubernetes。Kubernetes已经成为主流公有云平台上的首选容器编排平台。这些主流公有云平台包括微软的Azure容器服务以及GoogleCloud(参见GKE)。此外市面上还有很多好用的产品，来不断丰富快速扩大的Kubernetes生态圈。与此同时，那些试图用一层抽象将Kubernetes隐藏起来的平台尚未成功地证明自己的价值。

.NETCore

作为一个开源的跨平台软件开发框架，.NETCORE被越来越多地运用到实际项目中。该框架令.NET应用能在Windows、macOS以及Linux系统上进行开发和部署。.NETStandard2.0的发布增加了跨多个.NET平台的标准API的数量，这使得往.NETCore迁移的路径变得更为清晰。有关.NETCore对其上类库的支持性问题正在逐渐减少。一流的跨平台工具已经涌现出来，用于在非Windows平台上进行高效的开发工作。运用Docker镜像，能让.NETCore服务可以轻松地集成到容器环境中。其社区发展的积极方向以及来自我们实际项目的反馈，都表明.NETCore现在已经可以广泛地运用了。

TensorFlowServing

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

微信

常与WhatsApp被相提并论的微信，在中国正在成为名副其实的商业平台。很多人可能还不知道，微信还是最流行的线上支付平台之一。借助微信内置的内容和会员管理系统，一些小型企业现已完全依赖微信开展其业务。大型组织可以通过微信的一些功能把内部系统对接给员工使用。作为覆盖七成以上中国人的平台，微信是每一个想开辟中国市场的企业都需要考虑的重要商业因素。

语言服务器协议

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

作者：ThoughtWorks

来源：infoq

【免责声明】：本内容转载于网络，转载目的在于传递最新信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。