你能利用操作系统建立更好的软件架构吗？

你需要一个数据库和一个API吗？

照片：Lance AndersononUnsplash

我想提出一个免责声明，因为我即将推出那种让人生气的谈话。我不想把软件架构颠倒过来。今天的项目不仅复杂，而且通常受制于不合适的工具、不合理的最后期限和被误解的需求。我在这里要试图指出的，可能只是一个理论练习。你把你觉得有价值的东西拿出来，把剩下的留在理论练习的垃圾桶里。

讨论很快就会变得学术化。你用你喜欢的平台和开发语言工作，你用客户的要求工作，你用公司决定投资的东西工作。你有一套给定的库，允许你做各种任务。你可能使用一个数据库和一些服务，你所做的一切，你工作的每一项任务都依赖于这些依赖性和约束。如果是C#，它也可能是Entity Framework、SQL Server、Azure、.NET API等等，你能够在这个沙盒中完成每一项任务。作为一个软件开发者，生活是美好的，可预测的：它是有效的。

但在这个小沙盒的背后，有一个你很久以前就忘记了的可怕的生物。也许在早年你曾经驯服过它，但艺术被遗忘了，它的路径被隐藏了。现在你依赖平台、服务、当然还有云、数据库、lambda函数：一切都可以扩展，就像你的客户说的那样，一切都可以测试，就像建筑师说的那样，一切都在使用数据库，就像管理员说的那样，应该这样。但有时，一个文件解决了整个问题，绕过了所有框架、所有API、所有云基础设施。在你的应用层之外，还有而且永远是操作系统。

使用文件作为标志而不是数据库行

照片：Jan Antonin KolaronUnsplash

在我之前的工作中，我已经开始承认操作系统了。我们需要知道一个应用程序在部署后何时可以使用。我不记得当时的背景了：一些跨团队的要求。架构师很快决定用数据库中的日志来标记成功的部署，然后在API中创建一个端点来查询它。很简单，如果不是因为后端太丑的话。我从来不喜欢在上面添加东西。数据库也是如此。

我想了一下，提出了一个更简单的解决方案：如果部署很好，应用程序准备好了，让我们让构建过程在部署文件夹中添加另一个文件作为成功的标志。API可以直接检查文件的存在，并回答它是否存在。架构师思考了一下，提出了一个改进方案：不需要一个新的文件，构建过程已经在部署文件夹中创建了一些东西，可以作为一个随时可以使用的标记。他很高兴，因为这个解决方案的复杂性较低，我也很高兴：它更容易实现。

该解决方案也更坚固。创建文件是一个低级别的操作系统操作。如果它失败了，你肯定知道有什么地方出了大问题，如果你把这个操作与应用程序的部署联系起来，很明显部署失败了。在数据库中设置部署完成的工作方式有点不同。部署可能已经成功了，但数据库却无法到达。部署可能出了问题，但数据库没有正确更新。应用服务器和数据库服务器之间的通信可能已经失败。很多事情都可能出错。

检查文件夹中的文件是任何操作系统的一个基本行为。它也非常快，因为它处理的是文件系统元数据：它甚至不需要实际的文件读取。对于数据库来说就不是这样了。更不用说数据库可能需要为快速扫描建立一个索引，这也会使用额外的资源。

使用文件作为可编辑的数据存储

照片：Nguyen Dang Hoang NhuonUnsplash

一个朋友正在开发一个测验应用程序。他有复杂的测验，有分层的问题和依赖关系。最初的架构并没有受到挑战：问题是要进入数据库的。我再次建议他使用文本文件作为替代：任何人都可以很容易地编辑这些文件，不需要API，部署和构建也更快。他的最终解决方案甚至更好：markdown文件。

但是，让我们先考虑一下管理界面。问题都在文本文件中。每个操作系统都已经配备了一个文本编辑器。你真的需要建立API和一个额外的UI来添加和删除问题吗？你需要一个自定义的用户界面来从现有问题中创建一个新的测验吗？是的，当然也不是，这取决于编辑器和你需要的功能，但在最好的情况下，你可能什么都不需要：一个文本编辑器可能就够了。由操作系统提供。更不用说对于markdown，你还有更好的编辑器。

我们也来考虑一下架构：取决于其他问题的问题可能会被放在一个子文件夹里。当用户选择一个问题时，依赖的文件夹也会被调用并要求完成。对于验证，你可以有代码，或者你可以使用标记技术，如脚注或注释。

为了拥有这一切，是否值得删除数据库？我很乐意去掉一个应用层来简化架构。这是否会使开发变得复杂？嗯，它肯定会让你思考和计划更多，但如果你为所有需要的应用功能找到解决方案，开发应该更容易而不是更难，而且应用应该与操作系统分担责任。

使用系统日志而不是日志数据库表

照片：David PupazaonUnsplash

我正在开发一个需要关键日志的应用程序。我猜你现在可以预测到这个模式：架构师不假思索地决定使用一个表来做日志。我开始问一些问题：如果这个表很忙怎么办？如果数据库无法访问怎么办？如果通信被切断怎么办？当然，建筑师为他们的立场辩护：数据库符合ACID标准，写就是写，我们可以使用事务，等等。现实情况是，虽然说的都是真的，但我们没有办法确保日志能够进入数据库，更不用说它们是安全存储的。

实施的解决方案是使用Linux系统的日志。我们不得不在项目中添加一个处理系统日志的小库，对其进行配置，仅此而已。这个日志解决方案非常有效，我们决定完全放弃数据库日志，把所有的东西都记录到系统日志中。这不仅提高了应用程序的速度，因为在数据库中记录日志需要许多上下文、请求和等待，我们现在可以使用一些专门用于日志浏览的Linux工具来浏览日志，这些工具的构建和功能都非常好。比如我之前写过的 lnav 。

同样，我们利用了操作系统提供的服务。我们还使用了一个专门的工具来浏览日志，而不是建立另一个用户界面来检查日志。应用程序变得更简单了，失去了一个完整的日志管理UI，我们也学会了Linux系统日志和lnav 。让我告诉你，这两者在处理日志方面做得比我们所有的框架和库都要好得多。

为什么我们要挑战那些经过考验的解决方案呢？

照片：Dollar GillonUnsplash

我有更多的例子，也许有一天我会继续写这篇文章的第二部分，但现在我应该停下来，因为重点有些不同。我不想被误认为是说我们应该停止使用我们选择的编程生态系统提供的库或服务。或者尝试使用文件来处理所有事情。文件有一个时间和地点，就像软件平台一样。

我想做的是让你质疑平台、API、云解决方案、生态系统、数据库和更多我们每天都认为理所当然的可信赖和未受质疑的架构决定的使用。当然，我也想提醒你，你的朋友，操作系统。

操作系统有一个API，即允许你使用文件、线程、资源、套接字、消息队列等的系统命令。它还有一个数据库，带有文件锁的文件系统，甚至允许你锁定一个文件的一部分：一些用于阅读，一些用于写入。作为一个开发者，你需要知道在每种情况下什么能更好地帮助你：是编程语言，是库，是操作系统？你应该在一个表中写一行吗？一个文件就够了吗？

我希望我不会像那些放不下他们的汇编语言的老顽固那样。当然不是这样的。实际上，我已经决定了下一篇文章的内容，是的，它将是更多有缺陷的软件架构的例子。

所以，如果你觉得这篇文章空洞或肤浅，也许可以跳过下一篇。但是，如果它让你思考，如果软件利用更好的工具，而不是妥协的架构被迫工作，只是因为那是它的工作方式，那么我希望能在下一次见到你