如何用Lee Atchison[Podcast]架构您的应用程序

越来越多的业务量和更深层次的复杂性–这些只是组织在应用程序增长时所面临的一些共同挑战。为了管理应用程序的增长，必须设计它们来处理流量高峰和最小化停机时间。架构师需要将可用性和管理风险作为应用程序设计的一部分来考虑。

今天和我们一起喝一轮鸡尾酒的是一位经验丰富的专家。听取他关于组织如何通过改进可用性、为失败设计和管理风险来设计应用程序的合理建议。

成绩单

凯文·蒙塔尔博：好的。当然，托罗·云公司的首席执行官兼创始人大卫·布朗(DavidBrown)也加入了今天的一轮鸡尾酒之旅。嗨，大卫！

大卫·布朗：你好凯文！

知识管理：我们今天的嘉宾是一位经验丰富和公认的云计算行业思想领袖，他在设计和构建高需求的SaaS应用程序方面有着30多年的经验。

他通过专注于扩展和可用性、促进云迁移、DevOps转换和基于风险的问题分析，帮助公司实现应用程序的现代化。

他是O‘Reilly Media出版的“规模建筑师”(ArchitchingforScale)一书的作者。他也是一位著名的演讲者和行业专家，在几个出版物中被广泛引用，并在世界各地的活动中担任过专题发言人。

今天，他和我们一起参加了一轮鸡尾酒。李·阿奇森，很高兴你能上播客节目！欢迎。

李·阿奇森：谢谢。能来这里真是太好了。我甚至带了我的鸡尾酒准备好了。

DB：看起来像是一杯配橄榄的马提尼酒。是吗?

LA：嗯。就是这样。是

DB：非常合适。

知识管理：是啊，太完美了。所以，当我们阅读你的个人资料时，我们注意到它提到，在你担任亚马逊高级经理的七年期间，你领导了公司第一家软件下载商店的创建。您还创建了AWS ElasticBean秸秆，并管理着亚马逊零售平台向基于服务的新架构的迁移。那么，您能告诉我们更多关于将Amazon迁移到基于服务的体系结构的经验吗？

LA：当然，当然。嗯。所以，当我在亚马逊创立的时候，是在2005年，你知道，按照所有现代的定义，他们都是一家小公司。你知道，仍然有成百上千的员工–可能是整体员工–但一般都有大约100名工程师，无论谁在公司的零售部门工作，这当然比今天要小得多。但即使在这个层面上，他们也遇到了问题。他们遇到的最大问题是，他们设计了这个系统，所以每个通过网站的交易都必须通过这个名为Obidos的应用程序。“Obidos”这个词来自一个地方–我从来没有证实过这一点–但据报道，这是亚马逊河上的一个地方，所有的支流都从那里流入，形成了通往河流主要部分的漏斗。

当他们建造它的时候，他们想，“嘿，这太棒了。我们会把所有的东西都漏斗到一个地方，这最终会让建造这个更容易，”和所有这些伟大的东西。当然，我们现在都知道，这与构建应用程序的正确方法正好相反。他们遇到了这个问题。当我和大约100名工程师一起工作的时候，他们基本上是在以某种方式塑造或形成这一段代码–还有其他的服务–但是这一段代码被每个人都感动了。他们试着每周部署两次，但总有一些东西：一些没有运行测试套件的团队，或者一些做了更改并破坏了一些东西的团队，因此很少有实际的部署。这是应用程序的一个主要问题，它对应用程序的更改非常缓慢。

所以，他们建造了一个新的系统叫做Gurupa，我没有检查这个，所以据我所知，这个Gurupa是河的一部分，在它变窄之后，它又变宽了。所以整个想法是，“让我们构建这个应用程序，而不是有一个漏斗点，相反，我们有一个基础设施，我们可以插入所有这些模块，这些模块都是独立开发的、独立部署的、独立测试的–服务，基本上是前端服务和后端服务。我们将把整个网站都换成这个新模式，扔掉旧模式。“因此，在整个过程中，我认为这可能是一个为期两年的项目，他们把整个亚马逊网站从Obidos转移到了Gurupa。我是在船上工作的，当时是那个启动整个项目的人。

但是当它结束的时候，我正在运行一个团队，负责协调完成所有这些活动，然后转移到新的体系结构中去。最后，我们有大约一百名工程师在几个月甚至几个月的时间里工作，直到有一天，我们一点一点地做了一些迁移，但是我们大部分时间做了大部分的改变，在24小时的时间里，我们有了这个战争室，我们聚集在一起，我们在墙上有了一些度量标准，我们把手机还给了其他团队，是的，我们有真实的手机，我们给其他团队的真实的人打电话。我们都在这间屋子里，在一个晚上，整整一天的24小时里，一个国家一个国家地迁徙。

而且很棒。我的意思是，你知道我们的首席执行官来过，然后感谢我们，说“嗨”之类的话。我要和他握手。那是我第一次见到他。但这是一个让这一切发生的好时机。有一次，我们估计有0.1%的互联网流量因为这个项目而在那天发生了变化。我们用了这个术语，我们称之为“纽约时报事件”。整个想法是“纽约时报”的事件是坏事。就在那时，“纽约时报”(NewYorkTimes)上有一篇文章说，亚马逊(Amazon)又搞砸了。我们试着避开那些。我们的整个目标是在不产生“纽约时报”事件的情况下，努力度过一整天。

我们做到了，你知道吗？没有人注意到这一点，这是一个完美的外国观点。一切都很顺利，就这样发生了。我说，“这是一个伟大的项目。”这是我在亚马逊的第一个项目。这是一个伟大的项目，实际上是运行到最后，我在运行。这只是一次美妙的经历。同时，它也显示了我们当时学到的一些关于互联网的东西。在这之后，在大约一个月的时间里，交通开始落后，我们开始有问题，你知道，我们得到的搜索结果更少的发生了什么。现在到了十一月，黑色星期五，你知道，购物的时候，我们的搜索流量减少了，并且开始急剧下降。

嗯，那就是我们了解搜索引擎优化的意义所在。从字面上说，这是，你知道，我们有一个团队做了这件事，但我们真的不明白。这段时间，人们要弄清楚谷歌对搜索结果做了什么，什么真正推动了搜索结果，什么没有。我们当时不知道的是，显然现在所有人都知道这一点，但当时我们不知道的是，URL是搜索结果的一个重要组成部分。我们未能正确地进行重定向，这让谷歌感到高兴。

于是谷歌不再说，“嗯，他们已经不在了，所以我们不会再把流量发送到亚马逊了。”最后，它是一个未成年人，嗯，不是那么小，而是一个重大的紧急情况，我们在感恩节前的晚上做了一个小的修复，只是为了让交通恢复正常。它起了作用，每个人都很好，但是在感恩节之前，有一些压力很大的时刻，所有这些都发生了。令人惊讶的是，你学到的一些东西，我们现在认为是理所当然的，但在那时，是人们正在学习的关于互联网运作方式的新东西。

DB：你通过切牙来学习。这就是你对面向服务的体系结构的热情来源吗？

LA：是的，非常肯定。嗯。我学到了很多。我的意思是，你会听到亚马逊的各种好事和坏话，是的，这是一个高压锅的环境，是的，这是很难工作的。这是我做过的最好的工作，我再也不会做了。但是我学到了很多关于基于服务的架构，关于扩展，高可用性到底是什么，为什么保持可用性是重要的，以及当你不这样做的时候会发生什么。我可以讲各种各样的故事，但是当你坐在那里，吃感恩节晚餐，看着显示器，因为网站上有问题，你必须把它修好，你知道它影响了数百万美元的订单。此时，你正在看一张图表，它显示了当前订单中美元的数量，你已经看到这个图表像这样下降了，你可以看到可用性是什么以及它有多重要。因此，从这些年里，我学到了很多关于这些事情的重要性，以及该做些什么，以及进入AWS并在那里学习。

DB：那么，让我们跳过一些高可用性和规模架构的概念。那么，这一切都可以归结为面向服务的体系结构，现在是现代建筑世界中的微服务吗？

LA：好的。所以，我认为最简单的答案可能是否定的。我不认为今天你可以构建一个高可伸缩性和高可用性的现代应用程序，而不需要使用服务和面向服务的体系结构技术，不管是微服务还是传统服务，不管它是什么，但这还不够。您必须使用服务，但是扩展功能远远不止于服务。除了以面向服务的方式架构之外，在高可用性和高扩展中涉及到的最大的一件事可能是以正确的方式构建您的组织。

组织很重要。真的很重要。以及您的组织结构在扩展和可用性方面确实有很大的不同。在这本书中，我谈到了一个叫做STOSA的概念，它代表的是面向单一团队的服务体系结构。这是我在这本书中编出来的一个术语，但它有点流行，而且非常非常有价值。这是一个关于如何组织您的开发团队的概念，或者本质上是您组织公司的方式，这样您就可以构建一个可扩展和高度可用的应用程序。因此，很多内容都与DevOps主题、SRE主题和许多这类内容重叠，但它基本上涉及到服务的所有权。构建面向服务的体系结构是问题的一部分，分配所有权和定义所有权意味着什么是问题的另一部分。服务水平协议和服务间协议是极其重要的。我知道谷歌喜欢用SLO和SLIS这个词。我对一切都使用SLA一词，因为SLO一词意味着内部协议和SLI在某种程度上不如外部SLA那么重要。但它们并不重要，它们同样重要。

因此，我想在应用程序中的任何地方使用SLA这个术语，无论是您与客户达成的协议，还是一项服务与另一项服务就如何执行达成的协议，两者都是相同的术语。所以定义团队之间的SLA，你知道，当一个问题发生的时候，问题从哪里来，谁负责，谁负责，知道谁应该负责，这并不是什么错。它是关于找到问题，知道它需要什么来解决它，并知道谁来解决它。你需要做那些事。因此，您既可以扩展组织，也可以扩展应用程序。

DB：STOSA的概念，这是康威定律的延伸吗？

LA：所以它们当然是相关的，但我不认为它是直接的。但我确实觉得那里有某种关系。然而，您构建您的组织，甚至使用STOSA或不使用STOSA，将决定您的应用程序是如何被结构化的。那绝对是真的。康威定律就是这么说的，但我认为，你知道，STOSA真正谈论的是组织内不同团队如何相互作用的最佳实践和方法，以实现这一点。所以，我想这是康威定律的延伸。这是相关的，但似乎有点不同。

DB：它为组织团队的实施提供了蓝图和行动计划。

洛杉矶：没错。

DB：让我们谈谈可伸缩性的一些细节，所以我们有基于事件的体系结构，微服务，有不同的服务架构方式。在每一种情况下，有时我们必须管理状态，维护状态。某种意义上说，“这个人做了这件事”，并记住在下一个服务中的状态。那么，应用程序管理状态的方式有多重要，这又如何影响它们的扩展能力呢？

LA：是啊，所以在很多方面，国家都是我们的敌人。你知道，就像，你拥有的州越多，就越难扩大规模。事实上，最容易扩展的应用程序是无状态的，或者最容易扩展的服务是无状态服务。所以状态是非常非常重要的。在应用程序中，对于如何处理状态和如何处理数据，有很多不同的模型。我坚信，除了一些例外，该状态需要成为对该数据负有最大责任的服务的一部分。它是所有权模型的一部分，仅在整个应用程序中，就没有正确分布的集中式状态。因此，这往往表明您拥有更少的无状态服务和更多的有状态服务。无状态服务规模更大的想法似乎有悖常理，那么为什么会有更多有状态的服务器呢？但是，通过以这种方式传播状态，每个单独的服务都有较少的它必须担心的状态，并且能够处理它需要担心和适当扩展的状态的各个部分。它非常适合于扩展模型，组织的扩展也是如此。你拥有的数据越多，数据交互就越复杂，你越把它分开，在它之间设置障碍，你就越需要考虑数据之间的交互方式。在使用状态时，通常遇到的最大问题之一是，当您无法跟踪数据的电导率时，您就不知道应用程序中是否存在任何查询，在应用程序中，这个状态是根据这些数据被查询的。

你不知道是否有连接正在以奇怪的方式进行，这使得你在缩放的时候变得非常困难，那个数据库已经把数据分开了。你不可能轻易的做到这一点，因为你不知道是谁在使用它，也不知道它是如何使用的，但是如果你愿意的话，先把数据分割出来，然后把数据放在所有者旁边，放在最了解数据的人旁边，然后它使用数据最多，然后在服务之间构建一个API来访问这些数据，你可以预先做出非常清晰的边界，这会使扩展过程随着时间的推移变得更好。

DB：您还提到了团队之间的SLA。通常，当我们讨论扩展应用程序时，我们试图避免失败，但是架构师在构建用于扩展的应用程序时，是否真的应该为失败而设计呢？

LA：所以你知道绝对的。我非常喜欢混沌测试。Netflix最初推出的模型是黄金的，我在任何时候都在与一个组织合作的时候，我非常提倡的是，我谈论的是混乱。测试是应用程序的一个组成部分。我经常听到很多公司把混沌测试说成是他们在开发环境或准备环境中所做的事情。不，你想在生产中，在现场运行的生产系统中做混沌测试。你想做听起来很疯狂的事。您希望在生产中禁用服务。你想把他们关掉。你想打破他们。你想要对他们做一些奇怪的事情，而且你想要定期这样做。您想要不断地这样做，因为您希望看到您的系统是如何响应的。

当人们关注这个系统的时候，公司里的人都在关注这个系统，这样他们就可以理解系统中的故障是如何工作的，并且能够做适当的技术来防止这种情况的发生。你知道，我认为在一个程序员的情况下，他为某件事做了一个改变，你知道，这是服务A，服务A所做的事情之一就是它与服务B对话，有人说，“服务B的情况是下降的。”而且，你知道，通常的反应，我不担心。现在我有最后期限了。服务速度永远不会下降。我们会担心的。当这个问题出现的时候，我们就把它解决了，事情就会假设它会很好的工作，你刚刚在系统中引入了技术债务，因为服务B在某个时候会失败。

现在你有一个未知的问题发生了。但是，如果，你知道，作为一个工程师，服务B经常失败，你必须处理它。你不能做那些决定。你会说，“我现在就需要处理这个问题，因为在我部署之后，在某个时间点服务，速度将会失败，我将不得不处理它。”而且，你知道，这会发生的。你不会经常推迟这些决定，你会提前做出正确的选择。如果你没有做出正确的选择，不管是有意的还是偶然的，你都会注意到，而且你会更早地发现问题。当一些随机的事情发生时，你不知道发生了什么。所以我坚信混沌测试。我坚信建立失败的基础。我也是一个坚定的信念，常常很快就会失败，很快就会发现问题。

DB：采取一些信心来做混乱的测试和生产环境那里。对吗？

LA：的确如此。的确如此。这是一种非常难吃的药丸，对一家从未这么做过的公司来说，几乎是一种不可能的药丸–“好吧，现在我们要在生产中这样做了。”所以你通常得把它们建造成这样。你说，“好吧，让我们从分期开始。让我向你展示它是如何工作的。让我们做一些简单的事情。让我们把一台备用的服务器打开。让我们看看会发生什么。我会告诉你你是如何应对的。”你一点一点地构建它，一开始就建立混沌测试要比后来容易得多。不仅从技术的角度，而且从文化的角度。另一件事是，如果您正在开发一个新的应用程序，从一开始就构建这些扩展概念，这些可用性概念从一开始就存在，因为在您拥有一个客户之前考虑混乱测试要比在您拥有一百万用户之后要容易得多。

DB：你提到了引入技术债务的概念。我想，你知道，我们可能会有一个关于引进技术债务的播客，以后必须处理这些问题。但这就是概念，对吧？这是因为你没有及早认识或解决一些问题，你只是把它推到了轨道上，最终你将不得不重新审视它，它可能会比它所具有的更多的含义。

LA：是的，当然。而且，有时您是有意这样做的，并计划出于项目原因插入技术债务。而且，你知道，这是有好处的，也有缺点的。有时候你只需要这样做。只要你这么做，你知道，技术债务本身并不坏。你不知道的技术债务，这才是坏的。所以，如果你把技术债务作为一个商业决策投入到系统中，而你在知情的情况下这么做，或者你有一个计划，以后再删除它，你知道，这是风险管理的一部分，也是风险管理的一个重要部分，但是当你不知道它的时候，你做的事情会导致技术债务被插入，而你不知道你在做什么，而且以后的影响也会被未知，这是技术债务的一部分，尤其是，这是非常非常糟糕的。

DB：这就是你几次提到风险管理的原因。我知道你的书中有一节是关于风险管理的。什么样的概念？因为我们一直在谈论风险那么，我们谈论的风险和可伸缩性是什么呢？

LA：嗯。因此，我们谈论风险的主要问题是提前了解和计划风险。所以，你知道发生了什么，你可以制定计划。因此，我谈到建立一个风险矩阵，以及与我一起工作的团队，我期望每个团队为每个服务建立一个风险矩阵，定义他们所有已知的风险和他们对未知风险的想法，以及未知领域成为风险矩阵的一部分。并将严重性和优先级都分配给所有的人。然后，对它们进行排序，组织它们，对它们进行分类，并了解规划过程中的风险，以便以后如何添加新功能。这基本上是你的文件，如果你愿意的话，你的技术数据，你的风险计划。

现在，任何有一个空的风险矩阵的团队都会说：“嗯，我们真的非常好。我们已经解决了所有的问题。这里根本没有风险。”你知道，首先，他们在撒谎，或者至少，他们不明白发生了什么，但这意味着他们没有认真思考，他们需要花更多的时间想出来。你知道，你不应该有一个目标或期望，你的申请没有风险，但你想进入的状态，你没有尽可能少的未知风险。已知的风险是可以的，只要你知道它，有一个相关的缓解计划。我没有提到的另一件事是，对于风险矩阵中的每一个项目，你必须有一个缓解计划。如果这种风险真的发生了，你会怎么做？

所以如果这个问题真的发生了，我们会提前制定一个计划。也许这是你的运行手册或进程的一部分，或者是某些特定的情况，不管是什么，如果风险真的发生，你会提前知道你要做什么。所以你有风险，你可以计划好。风险是应用程序开发过程中自然的一部分，是一切事物的自然过程。它只是未知的风险或风险，你没有一个计划，你想要避免。因此，通过认识到风险，看到它，组织它，优先排序，然后计划它，你可以做好准备，当问题发生。这将提高可用性，并提高可伸缩性，因为随着规模的扩大，会引发许多风险。当风险发生时，这是一个共同点。

DB：你是对的。这就是与规模的关系。

LA：对吗？是。缩放和可用性密切相关。通常情况下，可用性问题通常会导致某种形式的可伸缩性问题，而扩展问题通常会回到可用性问题上。所以，当我谈到为扩展而设计架构时，我实际上是在谈论架构的可用性，因为它们是如此的交织在一起，以至于它们真的是一回事。

DB：嗯。可用性，尽管吞吐量，吞吐量不断增加。所以这是对的。因此，为了避免潜在的灾难，您已经讨论了微服务体系结构中服务层的标记系统。你能告诉我们这个概念吗？

LA：当然，当然。所以我有所谓的服务层，实际上，这不是我编造的东西。这是我们在亚马逊的工作非常有效的东西，我刚刚在其他地方完成了。我们所做的是分配四层：第一层到第四层。第一层是您最重要的业务服务。第四层是最不重要的商业服务。您将每个服务分配给一个层，一层业务关键服务的一个例子是一个服务，也就是说，如果该服务失败，您的应用程序就会失败。你别无选择。这方面的一个典型例子是登录面。如果网站应用程序对您没有用处，则无法登录该应用程序。

这是一级服务的一个很好的例子。显然有很多这样的例子。第四层服务的一个例子是在任何方式、形状或形式上都不是任务关键的服务。如果出现故障，您可以在没有任何人注意到的情况下运行您的应用程序，也可以让任何客户注意到某一段不重要的时间。第四层服务的一个很好的例子是后端报告服务，它可以报告系统所发生的事情的信息。我并不是说报告和度量并不重要，但它对应用程序的性能没有直接影响。因此，您将一个层与您的每一个服务相关联，并且在您的流程和系统流程中使用这些分层数字，以及几种不同的方式。一种方法是在问题严重性分配过程中。

因此，当您将票证或问题与服务相关联时，它的严重性会影响到这个问题的严重程度，但它也会被分配给一个服务，并且服务有一个分层编号。当您试图将对公司或团队重要的事情进行优先排序时，如果一个团队拥有一个以上的服务，那么您可以将这两个数字放在一起使用。显然，高严重性和高层服务是修复的最关键的东西，而低的严重性，低层是最不重要的修复。但二级问题、三级服务、三级问题和二级服务又如何呢？通过拥有这两个维度，您可以制定计划，首先修复哪些问题，修复哪些顺序问题，以及应用程序的不同部分有多重要。

使用服务层的另一个地方是服务之间的连接。因此，服务与其他服务对话，他们在不同层次上与其他服务对话。因此，如果你有一项关键任务服务，一项最终与第四层服务，一项非任务关键服务进行通信的服务，你最好有一个风暴计划来应对当第四层服务关闭时会发生什么，因为保证它会更频繁地停机。你会发现，你的服务会下降，这是一个令人满意的指标。因此，您需要能够弄清楚在该服务出现故障或不可用或有问题或其他情况下如何操作该服务。您调用的服务必须是可选的。相反，如果您有第四层服务调用第一层服务，您几乎可以忽略问题，因为如果第一层服务出现故障，系统中还会出现很多其他问题。

管理报告没有发布的事实并不是什么大不了的事。现在这是两个极端。细节在中间的交互中。你会惊讶于你发现了很多地方，比如说第二层服务和很多你没有真正意识到的第三层服务有联系。特别是这种组合是相当普遍的。因此，它提供了这些交互的可见性，这些交互可能会影响可用性和跨团队。这是STOSA的一部分，也是STOSA的一部分，就像组织一样，事情是如何运作的。它是SLA的一部分，但它只是标记和理解服务重要性的一种方式，这样您就可以应用流程来确保正确地处理交互。

DB：“规模建筑师”的第二版去年由O‘Reilly出版，我认为这是第一版出版四年后出版的。我猜已经发生了很大的变化。事实上，我自己读到了一些关于你在第二版中加入了什么的评论，这是这个行业的一些进步，比如无服务器计算，在你的旅游和演讲活动中，你和很多专家交谈过，你把他们的一些反馈纳入了这本书的第二版。在这四年里发生了什么变化？人们在第二版能看到什么？

LA：当然，当然。所以书中很多东西都变了，我肯定会具体回答你的问题，但我学到的一件事是，第一版的结构不像以前那么好，也不是最好的。因此，这本书被戏剧性地重组成五个不同的租户，它们更符合个人想要谈论的话题。这是发生的重大变化之一，但我增加了许多内容和几个关键领域，与行业的变化有关。有一堆与无服务器相关的内容适用。Serverless是大约四年前的东西，但它在曲线上的可接受性更高，它被用于更多的情况，也许比它应该使用的情况更多，但它在很多很多情况下都使用过。

在过去的四年里，边缘计算在重要性和流行程度上都有了很大的提高。人工智能和机器学习算法，以及它们在关键应用中的中心地位。你不能再在像语音识别这样的边缘区域看到它们了。您现在已经在应用程序核心的主流数据处理中看到了它们。你知道，即使只是用云，这么说似乎很奇怪，但是云现在已经成为主流了。四年前，情况似乎是这样的，但实际上并非如此，而且在某些行业和世界上的某些地区也是如此。举个例子，四年前，欧洲对云的使用非常，非常犹豫不决。亚洲非常非常普遍地接受了云。美国也差不多做到了。一些行业而不是其他行业。

欧洲在很长一段时间里都是反云的。他们只是不信任云，也不信任云的安全方面。在过去的几年里，大部分的情况都发生了变化，而且更多的人接受了，但是仍然有一些抵制者，你知道，在我最后一次出差的时候，我去的是在这个领域的一家公司，也是其中的一个大抵制者–那是在一年前，在大流行爆发之前，这个问题就发生了–但其中一个最大的抵制者仍然是瑞士的私人银行。这是一个巨大的行业，它断然拒绝使用云。只是不是他们的心态。这对他们的用例来说并不重要。因此，AWS在瑞士有多少个地区？当时他们没有钱，因为这不是他们的市场。

他们只是不能很好地闯进去。我不确定它是否仍然是零，或者他们现在是否真的推出了一个，但是你明白了。所以，与四年前相比，云现在已经变得更加主流了–它曾经是当时的对话，“好吧，我们会考虑云，但是告诉我们为什么需要它，它将如何工作。”现在的问题是，如果你不使用云，告诉我你为什么不使用，以及你要做什么。很多公司的谈话都发生了很大的变化。

DB：李·阿奇森，这是每一位建筑师都应该在他们的图书馆里拥有的书中的一本。非常感谢你今天加入播客。很高兴有机会再次与你们讨论一些更详细的问题，我们今天刚刚简要地讨论了这些问题。

LA：非常乐意。很明显，我喜欢谈论这些话题，也很高兴来到这里，谢谢你的邀请。

DB：太棒了。谢谢李。

LA：好的。所以Leeatchison.com，L-E-E-A-T-C-H-I-S-O-N.com是最好的地方。我有我所有的作品在那里，链接到其他事情和我正在做的事情。你可以在亚马逊买到这本书。如果您是O‘Reilly Safari成员，您也可以在O’Reilly Safari成员包中免费获得这本书。它也可以在其他平台上使用，但亚马逊是主要的平台。

知识管理：好吧，酷。非常感谢李。

如果你需要小程序开发，可以点链接进行询问福州小程序开发