最近几周，OpenAI对ChatGPT产生了很多兴趣，出现了各种有趣的用例。

在许多方面，这是与建筑师白板相当的AI，但它有很多用途，而不仅仅是绘制线条和方框。在这篇文章中，我想使用这项创新技术来演示启动软件架构过程的另一个用例。

就像在白板上画画一样，这个过程有点混乱，因为典型的相互作用会导致不断修改以找到最佳答案。本文旨在演示我在ChatGPT中成功使用的一些提问技巧，这些技巧产生了真正有价值的结果。

ChatGPT的一个警告是它仍在学习，所以不要期望一致性。在另一天问同样的问题可能会产生不同的结果。

设置ChatGPT帐户本身很简单，可以按照以下地址的说明进行操作：https://openai.com/blog/chatgpt/

用户故事

因此，让我们先让ChatGPT对用户故事做出回应。

正如你所看到的，这个用户故事是我所在行业特有的。ChatGPT拥有庞大的知识库，因此需要进行实验来了解ChatGPT的知识深度——它知道什么？

第一个问题的关键是非常明确关键细节，以获得最佳结果。通过这种方式，ChatGPT可以得到一组不错的结果，例如：

如果您的结果与上述类似，那么您知道ChatGPT已经找到了线索，并将基于您提出的进一步问题。要记住的关键是，以下所有结果都将基于这个初始上下文，因此，为什么值得花时间好好定义第一次交互。

所以现在我们可以做一些非常了不起的事情。建立一个数据库！

让我们制作一个数据库

…这就是ChatGPT的响应方式：

但我们不要就此止步。让我们继续…

CREATE TABLE Surveyors (
    id INT NOT NULL AUTO_INCREMENT,
    name VARCHAR(255) NOT NULL,
    email VARCHAR(255) NOT NULL,
    password VARCHAR(255) NOT NULL,
    PRIMARY KEY (id)
);

CREATE TABLE Buildings (
    id INT NOT NULL AUTO_INCREMENT,
    type_id INT NOT NULL,
    coordinates VARCHAR(255) NOT NULL,
    notes TEXT,
    surveyor_id INT NOT NULL,
    PRIMARY KEY (id),
    FOREIGN KEY (type_id) REFERENCES BuildingTypes(id),
    FOREIGN KEY (surveyor_id) REFERENCES Surveyors(id)
);

CREATE TABLE BuildingTypes (
    id INT NOT NULL AUTO_INCREMENT,
    type VARCHAR(255) NOT NULL,
    PRIMARY KEY (id)
);

…ChatGPT以完全可接受的SQL响应，SQL数据库创建时不会有问题。然而，让我们不要再止步于此…

创建图表

<script src="https://cdn.jsdelivr.net/npm/mermaid@8.6.0/dist/mermaid.min.js"></script>
<script>mermaid.initialize({startOnLoad:true});</script>

<div class="mermaid">
classDiagram
class Surveyors {
+id: int
+name: string
+email: string
+password: string
}
class Buildings {
+id: int
+type_id: int
+coordinates: string
+notes: string
+surveyor_id: int
}
class BuildingTypes {
+id: int
+type: string
}
Surveyors --> Buildings
Buildings --> BuildingTypes
</div>

ChatGPT生成的图表如下…

ChatGPT充满惊喜：

ChatGPT不会显示图表，而是在Mermaid脚本中生成代码，该脚本将创建图表。ChatGPT完全熟悉美人鱼脚本，因此它可以生成这种脚本语言所允许的图表。

编程

正如我们已经建立的那样，ChatGPT已经学会了编码，因此您可以继续要求ChatGPT编写JavaScript、CSS和HTML，通过简单的请求将一个工作的原型放在一起。ChatGPT经过培训，可以用许多流行的编程语言生成代码。

如果有足够的时间，这是一个熟练的人可以做的事情。但这不是生产就绪代码；要使代码达到这样的质量和实用性，需要做更多的工作。但ChatGPT没有理由在做这件事时袖手旁观。

因此，让我们尝试使用ChatGPT提高代码质量：

ChatGPT是这样回应的：

public class Surveyor
{
    private readonly string _name;
    private readonly string _email;
    private readonly List<ISurvey> _surveys;
    private readonly IDatabaseAccess _databaseAccess;

    public Surveyor(string name, string email, IDatabaseAccess databaseAccess)
    {
        _name = name;
        _email = email;
        _databaseAccess = databaseAccess;
        _surveys = new List<ISurvey>();
    }

    public void AddSurvey(ISurvey survey)
    {
        try
        {
            _surveys.Add(survey);
            _databaseAccess.SaveSurvey(survey);
        }
        catch (Exception ex)
        {
            // Log the error
        }
    }

    public void RemoveSurvey(ISurvey survey)
    {
        try
        {
            _surveys.Remove(survey);
            _databaseAccess.DeleteSurvey(survey);
        }
        catch (Exception ex)
        {
            // Log the error
        }
    }

    public List<ISurvey> GetSurveys()
    {
        try
        {
            return _databaseAccess.GetSurveys();
        }
        catch (Exception ex)
        {
            // Log the error
            return new List<ISurvey>();
        }
    }
}

public interface IDatabaseAccess
{
    void SaveSurvey(ISurvey survey);
    void DeleteSurvey(ISurvey survey);
    List<ISurvey> GetSurveys();
}

public class DatabaseAccess : IDatabaseAccess
{
    public void SaveSurvey(ISurvey survey)
    {
        // Implementation for saving the survey to a database
    }

    public void DeleteSurvey(ISurvey survey)
    {
        // Implementation for deleting the survey from the database
    }

    public List<ISurvey> GetSurveys()
    {
        // Implementation for retrieving a list of surveys from the database
    }
}

public interface ISurvey
{
    decimal Latitude { get; set; }
    decimal Longitude { get; set; }
    string BuildingType { get; set; }
    Dictionary<string, string> BuildingCharacteristics { get; set; }
}

public class Survey : ISurvey
{
    public decimal Latitude { get; set; }
    public decimal Longitude { get; set; }
    public string BuildingType { get; set; }
    public Dictionary<string, string> BuildingCharacteristics { get; set; }

    public Survey(decimal latitude, decimal longitude, string buildingType, Dictionary<string, string> buildingCharacteristics)
    {
        Latitude = latitude;
        Longitude = longitude;
        BuildingType = buildingType;
        BuildingCharacteristics = buildingCharacteristics;
    }
}

……作为一套开始上课的课程，这多少有些令人尊敬。

我让ChatGPT做的下一个任务是为基于REST的API创建Swagger。ChatGPT再次做出了值得尊敬的努力，足以开始开发。

结论

ChatGPT可以开始开发，因为它具有广泛的功能，但尚未显示其深度。每次转弯时，我都必须让ChatGPT来完成任务；那里没有主动权，我已经开始并推动下一步行动。

然而，开发一组你知道的标准问题会促使ChatGPT提供一个好的结果，这可能很简单。在sprint计划中，这可能足以以多种方式开始开发。

这项技术现在就在这里，我们不妨完全接受它并继续实验，这样我们就可以进一步了解这种先进的自动化可以继续提供什么价值。

一个人如何想出一个真正原创的想法？ 一个改变了几个世纪的社会。

了解数字零的发现，以及它的哲学表现——虚无——改变了我对变革性思维的定位。

读完《零：一个危险想法的传记》后，我的第一个想法是，我想建立一个坚固的心智模型来探索类似的难以理解的概念。 我想找到大写的Z Zeros。

直觉上，这是我出售公司 Braintree Venmo 多年后一直在尝试做的事情，但我只是没有文字或概念来具体化我有意识地经历的事情。 当我出售公司并可以重新探索时，我试图回答的问题是：我能做些什么来帮助人类最大程度地繁荣发展？ 时代精神缺少什么但必不可少？

硅谷到处都是“第一原则”公司以及工程师和设计师的想法。但是我评估的每一个“第一原则”衍生的可能性都感觉它没有达到广泛的可能性，也没有达到人类现在为未来存在所需要的东西。跳出框框思考可以带来富有成效的见解，但这还不够；我想质疑盒子本身。

现在，当我运行 Kernel 和 OS Fund 时，我每天都在想 Zeros，这两家公司试图开创人类意义的未来。每一个都同时通过第一性原理思维实现，并由零发现推动，时间锁定在我们所有未来（2025 年、2050 年和 2500 年）有意义的视野。

零发现很难用我们今天可以使用的词语和概念来表达，但我知道找到零的情感概况。在对 AlphaGo 与世界上最好的人类围棋棋手的一场比赛进行专业分析时，一位观察者表示，这些动作就像是在观看 AI 下的“从另一个维度围棋”。那是个人资料。这就是见证零发现的感觉。

自从听到这个，我不断地回到这个“从另一个维度”的想法。对于训练有素的人来说，AlphaGo 似乎在玩新的想法或策略，这些想法或策略要么是全新的，要么是古老到足以被现代专业人士抛弃的。 AI 并没有将我们人类的假设视为既定事实，而是使用潜伏在游戏结构中的新概念原语进行游戏，即使专家也无法看到。这些动作已经存在。如果他们知道的话，人类可以玩它们。他们总是可能的。但人类大脑的某些东西让我们从未见过它们，即使在我们迭代了数千年的围棋文化和策略之后。为什么不？

AlphaGo 在围棋游戏中找到了零点，但围棋是一个有限的、完全信息的游戏。我的主要兴趣：我们如何为智能存在的未来找到最好的动作——那些“来自另一个维度的”？

上一代人从未有过我们现在所做的机会：看看我们预期的一生，并看到进化为/进入全新的意识体验形式的真正可能性。一个如此转变的存在，以至于我们现在的自己，以及今天的现实，将在历史上显得原始而无趣。

这些可能是什么？根据定义，零是无法定义的，也很难想象。我想到了一些：如果我们的动力不是社会地位、别人的认可或财富积累怎么办？如果我们没有感觉到部落的倾向怎么办？如果我们主要关心的是和谐游戏，一种我们今天甚至没有语言或概念的类型，与我们周围的一切事物？ （[输入你最不直观、最违反直觉和不太可能的断言] 你在想什么我看不到的？）毕竟，我们的现代世界会出现所有这些东西，对我们的祖先来说同样陌生。

即使是在几十年前，这些沉思也很容易被认为实际上是不可能的，或者对于任何真正想要完成某事的人来说都是浪费时间。 （当我们建立我们的自主自我时，我们的精神能量将被释放以探索这些前沿。）
从我们如何应对气候变化、我们如何适应技术颠覆、我们如何构建人工智能、我们如何管理自己，以及我们如何发展和激发我们继续前进的理由，以保持现存的。

最近，我浓缩了这些想法，开始练习“零原理”思维，旨在发现变革性的新思想元素。它是具有“第一原则”思维的双胞胎。零原理思维是关于构建块或所有事物的结构，而第一原理思维是关于系统规律或事物如何相互作用。第一性原理思维以已知术语设定目标，然后追求它们，必要时发明和学习新事物，但它很少发现世界需要的那种全新的概念原语。

当人们说“从第一原则……”开始他们的论点时，他们的意思是他们希望在给定的框架内假设尽可能少的事情。太空探索的创新是一个很好的例子，说明了仅来自第一原理思考的好处。我们今天在太空的议程很有价值，也很困难，我们没有宇宙中存在的所有答案，但我们确实对问题和构建模块有很好的了解。很长一段时间以来，几乎没有发现用于太空旅行的新构建块——我们仍在研究 1970 年代相同基本概念的含义和规律，可以说，从牛顿一直追溯到。

夏洛克·福尔摩斯是一位经典的第一原则思想家，凭借他自己的谨慎逻辑品牌取得成功：“当你消除了不可能的事情时，剩下的任何事情，无论多么不可能，都必须是真实的。”在这一点上，福尔摩斯——毕竟被困在一本书中——可以假设一个封闭的物体宇宙，如果 X 和 Y 是唯一存在的事物，则非 X 与 Y 相同。
然而，道格拉斯·亚当斯（Douglas Adams）创造的与福尔摩斯（Sherlock Holmes）形成对比的“整体侦探”德克·詹特利（Dirk Gently）的演绎却有不同的方法：“我不喜欢消除不可能的事情”。这就是零原理思维。看穿盲点。

在谋杀案调查中，福尔摩斯不会考虑时间旅行可能发挥作用的可能性，甚至假设。不过，德克·金特利不排除这种可能性。部分原因是他怎么知道什么是可能的，什么是不可能的？这两种虚构的检测风格说明了逻辑上的根本区别。
说“从零原则……”是什么意思？

零阶技术

人类生存的未来不能仅从第一性原理思维推导出来。我们需要零探险家。如果我们不能完全模拟我们要去哪里或我们可以追求什么，那么制定具有明确目标并激发大规模合作的实际计划将具有挑战性。我认为这是一个功能，而不是一个错误。

我们与 AI 共同进化的未来将引入创纪录数量的类似零的构建块，这反过来又会提升我们的抱负。当大脑接口允许一个人的思想与人工智能实时配对时，我们可能会体验到类似寒武纪大爆发的 Zeros 的出现。我们的潜意识之于我们的思维，就像深度学习之于人工智能一样，当人工智能被利用时，它将能够产生看起来像是“来自另一个维度”的思想。

根据定义，你不能“归零”或直接在思考中引入新元素，所以你必须尝试将第一性原理的努力推向极端，直到没有边际收益。作为智能系统架构师的人类如何提高零发现的速度？
首先，来自技术和科学的更多示例：

• Andrej Karpathy 的软件 2.0 愿景是零阶软件工程，它使用“抽象的、对人类不友好的语言”通过深度神经网络 (DNN) 实现目标。这与软件 1.0 形成鲜明对比，在软件 1.0 中，人类编写显式代码来实现目标。也许 Karpathy 的范式可以标记为 Software 0.0？
• Daniel Dennett 的“Joosting”（跳出系统）概念旨在发现 Zeros。
• 当爱因斯坦假设所有观察者的光速可能是恒定的时，他发现了零，这揭示了一个新的概念原语。字面意思是“从另一个维度移动”。

或者，考虑引入零（原始的字面数字/概念）之前和之后的欧洲几何的历史例子。欧洲人认为他们对数学的理解必须从头开始重建，以在引入零概念后包含它。并不是说希腊时代的欧几里得元素突然变得过时或毫无价值。零的力量在于它允许重建现有的数学，以便对包括零概念在内的几何有更强有力的理解。这导致了笛卡尔几何——包括平面上坐标系原点在 (0, 0) 处的想法——并且突然之间，几何和代数可以通过十进制在概念上联系起来。

在欧洲人了解零之前，笛卡尔不可能提出笛卡尔几何。任何人都曾尝试过做越来越好的欧几里得几何。
我们需要更多这样的见解。在一个我们不断扩大我们的理解范围的世界里，每一个第零原理的洞察力都有可能解锁一组更广阔的领域。这不仅仅是由 Ray Kurzweil 推广的那种指数效应，即“向上”/曲棍球棒/曲线膝盖风格的东西。零是游戏规则的改变者。该图不仅是指数的 - 单位会发生变化。该图重新组织其轴。添加维度以适应“来自另一个维度”的想法。这就是 Zeros 带给你的东西。

在您发现新的构建块并了解它们的属性之前，您不知道什么大目标值得追求。

这是一个大问题，零探险者的口头禅：哪些概念隐藏在显而易见的地方，但任何人都看不到？我们如何以有限的人类认知开始“从另一个维度”思考？
与其渴望成为第一，不如成为零。

原文：https://medium.com/future-literacy/zeroth-principles-thinking-9376d0b7e…

本文：https://jiagoushi.pro/zeroth-principles-thinking

对思维导图感兴趣 — 阅读我们关于使用 plantUML 和 ChatGPT 创建很棒的思维导图的博文

继续我之前的帖子，我想专注于 C4 图表模型。 为了不让 ChatGPT 偏离初衷，我从下面的提示开始

提示：展望未来，我希望你充当软件架构师并使用 mermaid.js 构建 C4 图。 保留降价语法的答案，并始终牢记软件功能和非功能方面，包括但不限于可伸缩性、可用性、冗余、容器化、安全性和灾难恢复。
ChatGPT：当然，作为一名软件架构师，我可以帮助您使用 Mermaid.js 创建 C4 图，这些图考虑了功能和非功能方面，例如可扩展性、可用性、冗余、容器化、安全性和灾难恢复。

C4图是表示软件系统架构的一种方式，分为四个主要层次：

• 上下文级别(Context level)，表示与系统交互的外部因素
• 容器级别(Container level)，表示部署单元及其依赖项
• 组件级别(Component level)，代表系统的不同组件
• 代码层级(Code level)，代表了系统的实现细节

好的，让我们开始吧

上下文图(The Context Diagram)

Prompt: Let’s start by creating a context diagram of the services in Wealth Management
ChatGPT: Sure, here’s an example of a context diagram in Mermaid format for a Wealth Management System:

 

在markdown 编辑器中

context diagram

此图显示了与财富管理系统交互的主要参与者以及系统提供的主要服务。

• 用户与账户管理服务、投资组合管理服务、资产管理服务和交易管理服务交互。
• 金融机构还与账户管理服务、投资组合管理服务、资产管理服务和交易管理服务交互。
• 市场与市场数据服务交互。
• 此图概述了参与者和服务之间的主要交互，它可能有助于理解系统的高级架构。

容器图(The Container Diagram)

到目前为止看起来不错。 接下来，让我们为其中一个服务构建一个容器级别的图表

Prompt: Let’s take the Portfolio service and break it down by creating a container diagram for its sub-functionalities
ChatGPT: Sure, here’s an example of a container diagram in Mermaid format for the Portfolio Management Service of a Wealth Management System:

Container diagram

and markdown diagram

此图显示了组成投资组合管理服务的容器及其依赖项。

• Portfolio Management API 是用户和其他系统与服务交互的入口点。
• 投资组合管理工作者负责执行后台任务，例如根据市场变化更新投资组合。
• 投资组合管理数据库存储与投资组合相关的数据，如每个投资组合中持有的资产、它们的当前价值等。
• 负载均衡器在 Kubernetes 集群中运行的投资组合管理 API 实例之间分配传入流量。
• Kubernetes 集群负责管理容器的扩展、可用性和部署。

组件图(The Component Diagram)

Prompt: Next lets create the component level diagram for portfolio management api with all relevant details
ChatGPT: Here’s an example of a component diagram in Mermaid format for the Portfolio Management API

and the corresponding mermaid diagram

Component diagram for Portfolio Management API

这是描述

此图显示了构成 Portfolio Management API 的不同组件及其依赖关系。

• 投资组合管理 API 的 API 网关组件是传入请求的入口点。
• 身份验证组件负责对用户进行身份验证。
• 授权组件负责检查用户的访问权限。
• Request Validator 组件负责验证传入的请求。
• 业务逻辑组件负责处理请求和执行业务逻辑。
• Response Formatter 组件负责在将响应发送回客户端之前格式化响应。
• 投资组合服务组件负责执行与投资组合管理相关的操作，如创建、读取、更新和删除投资组合，并与投资组合管理数据库通信以保存与投资组合相关的数据。

这看起来棒极了。 大多数细节与我的理解一致。 让我们尝试为 Portfolio Management Worker 构建相同的

Prompt: can we do the same for portfolio management worker container
ChatGPT: Sure, here’s an example of a component diagram in Mermaid format for the Portfolio Management Worker container of a Wealth Management System:

and the mermaid diagram

Component Diagram for PM Worker

此图显示了构成 Portfolio Management Worker 容器的组件及其依赖项。

• Task Scheduler 组件负责安排更新公文包的后台任务。
• 投资组合更新器组件负责根据市场变化更新投资组合，它与市场数据服务通信以获取最新的市场数据。
• 市场数据服务组件负责为投资组合更新程序提供市场数据。
• 投资组合服务组件负责执行与投资组合管理相关的操作，如创建、读取、更新和删除投资组合，并与投资组合管理数据库通信以持久保存与投资组合相关的数据。

代码图(The Code Diagram)

让我们做最后一点，并为 Portfolio Management API 创建代码图

Prompt: Can you also do the code diagram for Portfolio Management API
ChatGPT: Sure, here’s an example of a code diagram in Mermaid format for the Portfolio Management API of a Wealth Management System:

但是，当我尝试使用 Mermaid.js 在markdown 编辑器中创建它时，它无法指示循环依赖性。 我们在这里需要做的就是删除这些，如下所述

Corrected Code Graph

and the mermaid diagram

Portfolio Management API code packages

此图显示了构成 Portfolio Management API 的不同包及其依赖项。

• api 包是应用程序的入口点，它定义了路由和中间件。
• auth 包负责请求的认证和授权。
• 配置包负责加载配置文件。
• 控制器包负责处理请求和调用服务。
• errors 包定义自定义错误。
• 中间件包负责为处理 CORS、请求验证等请求提供中间件。
• 模型包定义了数据库实体的 ORM 模型。
• 服务包负责执行业务逻辑并与数据库通信。
• utils 包提供实用功能

太棒了，这是一篇描述 ChatGPT 功能的博客文章，尤其是在 C4 图表模型上。

谢谢阅读！

软件是必不可少的。 用于创建我们每天都依赖的软件的主要架构模式是什么？

世界几乎每一项人类活动都越来越依赖软件。从我们用来与他人联系的移动应用程序到医疗保健应用程序和深度学习模型，从金融技术系统到利用技术自动化许多活动的智能建筑，软件系统已经渗透并简化了人类生活的许多方面。为了让这些软件系统提供我们想要的解决方案，它们必须建立在正确的架构上以产生最佳结果。

什么是架构模式？

就像建筑物的架构一样，软件架构描述了将组件设计和收集到构成软件构建块的系统中。软件架构解释了软件程序的结构组成和元素之间的交互。为这些软件系统定义软件组织模式的原则称为架构模式。

架构模式捕获各种系统和软件元素的设计结构，以便它们可以被重用。在编写软件代码的过程中，开发人员在一个项目中、公司内部以及他们的职业生涯中多次遇到类似的问题。解决这个问题的一种方法是创建设计模式，为工程师提供解决这些问题的可重用方法，允许软件工程师在结构上为给定项目实现相同的输出。

从工程师的角度来看，软件架构模式很重要，因为它们提高了效率和生产力。由于开发人员已经了解项目中使用的架构模式，因此开发人员可以在任何时候加入有限的入职培训项目。新功能也可以毫无困难地添加到项目中，并且可以轻松解决常见的应用程序问题。

从客户的角度来看，架构模式优化了开发成本，加快了项目的时间线，并允许工程师交付高质量的产品。成本估算是基于对架构系统的理解，因此产品经理拥有更准确的项目成本，从而可以进行早期规划和预算。此外，明确定义的架构意味着系统已经过验证和范围。这有助于工程师专注于产品的基本要素，并允许管理人员为项目完成做好充分的计划。

有不同类型的软件架构模式，但在本文中，我们将探讨其中的五种以及它们如何成为软件开发的组成部分。

模型-视图-控制器模式

模型-视图-控制器 (MVC) 模式将应用程序分为三个组件：模型、视图和控制器。

模型是模式的核心组件，包含应用程序数据和核心功能。它是软件应用程序的动态数据结构，它控制着应用程序的数据和逻辑。但是，它不包含描述数据如何呈现给用户的逻辑。

视图显示应用程序数据并与用户交互。它可以访问模型中的数据，但无法理解数据，也无法理解如何操作数据。

控制器处理来自用户的输入并在模型和视图之间进行调解。它监听来自视图或用户的外部输入并创建适当的输出。控制器通过调用模型上的方法来与模型交互以生成适当的响应。

这三个组件通过某种形式的通知进行交互，例如事件或回调。这些通知包含状态信息，例如状态更改，它们被传达以更新这些组件。例如，可以将来自用户的外部事件传输到控制器以更新视图。因此，MVC 模式将软件组件解耦并允许轻松重用代码。

JavaScript、Python、Java 和 Swift 等主要编程语言都有 MVC 框架来开发 Web 和移动应用程序。 Web 应用程序框架，例如 Ruby on Rails 和 Django（用于 Python）都是基于这种架构。

MVC 模式的一个优点是多个工程师可以同时处理所有三个组件而不会发生冲突。此外，MVC 允许对相关输出进行逻辑分组，以从模型中生成大量视图。然而，一个缺点是导航框架可能很复杂，因为它引入了几个抽象层。

有用的参考资料：

• 通过编码恐怖理解模型-视图-控制器（2008）
• 来自原始 XEROX PARC 的 MVC 定义 (1978-79)
• Codecademy 对 MVC 的介绍

微服务模式

微服务模式涉及创建多个可以相互依赖地工作的应用程序或微服务。尽管每个微服务都可以独立开发和部署，但其功能与其他微服务交织在一起。

微服务模式中的一个关键概念是单元的单独部署。这创建了一个简化的交付管道，允许轻松部署微服务并提高应用程序的可扩展性。该模式的另一个关键特性是它是一种分布式架构，这意味着该结构的组件可以完全解耦，并可以通过 REST、SOAP 或 GraphQL 等远程访问协议进行访问。该模式的这种分布式特性使其具有高可扩展性。

微服务架构使用了几种设计模式：聚合器模式、API 网关设计模式、责任链模式、分支模式和异步消息传递设计模式。每种方法都提供了一种操作数据以产生服务的方法。

微服务架构的一个主要优势是每个微服务的独立部署。工程师可以独立于其他微服务编写和维护每个微服务，从而潜在地增加其功能和可扩展性。此外，由于每个微服务都很小，因此更容易重写和更新。微服务架构最适合具有小型组件的 Web 应用程序和网站。它对于边界明确的企业数据中心也很有用。微服务面临的一些挑战来自复杂性，尤其是在网络层。此外，将服务解耦以完全独立工作需要大量的架构专业知识。

有用的参考资料：

• Martin Fowler (2014) 的微服务定义
• 微服务架构中的分布式事务模式 (2018)
• 微服务教程，包括 Kubernetes 实践

客户端-服务器模式

在客户端-服务器架构模式中，有两个主要组件：客户端，即服务请求者，以及服务器，即服务提供者。尽管客户端和服务器可能位于同一系统中，但它们通常通过网络在不同硬件上进行通信。

客户端组件启动与服务器的某些交互以生成所需的服务。客户端组件具有描述所需服务的端口，而服务器具有描述它们提供的服务的端口。这两个组件都由请求/回复连接器链接。这种架构模式的一个典型例子是万维网。客户端-服务器模式也用于在线应用程序，例如文件共享和电子邮件。

一个简单的例子是网上银行服务。当银行客户使用网络浏览器访问网上银行服务时，客户端会向银行的网络服务器发起请求。在这种情况下，Web 浏览器是客户端，使用客户的登录详细信息访问银行的 Web 服务器以获取数据。应用程序服务器使用银行的业务逻辑解释这些数据，然后将适当的输出提供给 Web 服务器。

这种架构模式的一个主要优势是数据的中央计算；所有文件都存储在该网络的中心位置。因此，数据以及网络外围设备都是集中控制的。然而，一个缺点是服务器的购买和管理成本很高。

客户端-服务器模型与点对点架构模式相关，通常被描述为该模式的一个子类别。后者使用分散系统，其中对等方直接相互通信。

有用的链接：

• 什么是客户端-服务器架构？
• Red Hat 对 REST 架构的介绍

控制器-响应者模式

这通常被称为主/从架构模式，但由于它不是一个有用的比喻，一些工程师和软件公司采用了替代术语，如主/从、主/副本、父/助手、主/副本或控制器/响应者模式。最值得注意的是，IEEE 已将此作为网络技术的更好术语。

与客户端-服务器架构模式一样，此模式由两个组件组成：控制器和响应器。控制器组件在相同的响应器组件之间分配输入或工作，并从每个响应器生成的结果中生成复合结果。

简单来说，控制器是实际的数据保管者，而响应者复制存储在控制器数据库中的数据。写入数据仅在控制器数据库中完成，由响应者数据库读取。控制器确定响应者的通信优先级并对其进行控制。这与点对点架构模式不同，其中计算机平等通信并分担责任。

控制器-响应者模型的一个示例包括使用盒式磁带或光盘记录器完成的复制。

这种模式的一个关键优势是可以从响应程序组件中读取分析应用程序，而无需更改控制器组件的数据内容。此外，响应者可以离线并同步回来，而不会浪费任何时间。但是，当控制器发生故障时，所有数据都可能丢失，并且可能必须重新启动应用程序。在这些情况下，响应者可能会被提升为控制者，但并非没有一些数据和技术缺陷。

有用的链接：

• 来自 IEEE (2006) 的分布式进化计算的主从架构分析
• Packt 的主从架构

分层图案

分层架构模式在开发人员中最为常见。它对于包含多组子任务的程序很有用，每组子任务都处于不同的抽象级别。这些子任务中的每一个都由软件中的一个层表示——一个产生一组内聚服务的模块单元——并且每一层以单向模式向下一个更高层提供服务。

每一层在应用程序中都有一个特定的角色，该角色与其他层的角色相关联。例如，表示层（也称为 UL 层）将处理所有 UI 和浏览器通信逻辑，而业务逻辑层将执行某些业务请求。

其他类型的层包括应用程序层和数据访问或持久层，然后访问数据库层。这允许分离数据库层，并使您能够从 Oracle 服务器切换到 SQL 服务器，而不会影响其他层——它可以降低转换成本。

这些层以单向模式交互，因此当用户发起输入（例如单击按钮）时，表示层将消息发送到较低层，即应用层，后者又调用业务层，然后是数据访问数据库的访问层。因此，呼叫以分层模式向下流动，从较高层流向较低层。

分层架构模式存在于许多电子商务 Web 应用程序和桌面应用程序中。它对于需要快速构建的应用程序和需要采用传统 IT 流程的企业应用程序也很有用。此外，分层模式非常适合需要严格的可测试性标准的应用程序。

这种模式的一个关键优势是它允许以一种简单的方式来编写一个组织良好的应用程序。由于它是一种流行的架构模式，因此开发人员已经了解它的使用方式。但是，它确实有两个主要缺点：复杂性和添加更多层的成本。这些层最终可能难以拆分。

有用的参考资料：

• Mark Richards 的软件架构模式中的分层架构
• 软件架构模式 — Priyal Walpita 的分层架构

底线

其他几种架构模式，包括管道过滤器模式、黑板模式、代理模式和事件总线模式，在软件开发的不同方面也很有用。这个概念对所有人都是一样的：定义应用程序的基本特征，增强产品的功能，提高应用程序构建过程的效率和生产力。

但是，使用错误的架构模式可能会延迟您的项目，甚至可能导致软件故障。因此，关键是要充分了解架构模式以及它们最适合哪些应用程序，以便您可以选择适合您的软件需求的应用程序。

原文：https://www.redhat.com/architect/5-essential-patterns-software-architec…

本文：https://jiagoushi.pro/node/1930