后端软件体系结构核对表：如何从头开始构建产品

某天早上你醒来，喝着咖啡，瞧，尤里卡时刻就在这里。你终于弄清楚了你的商业模式，一切都井井有条。你知道投资者会喜欢它的，你只是迫不及待地想开始建造这个产品。先发优势在你手中。

这些时刻很少见，但当它们发生时，你需要在正确的时间启动。你所需要的只是一本正确的指南，帮助你找出应该做什么，不应该做什么。现在不是试验的时候，现在是执行的时候。现在是你的时候了！

注意-以下内容与从头开始构建软件体系结构相关。因此，如果您有兴趣了解所涉及技术的本质，那么请继续。否则，请与那些肯定会喜欢它的人分享：p。

我自己也做过几个早期产品，老实说，我确实犯过错误。我总是希望在从头开始开发产品的时候能有一个可以遵循的清单。

从头开始构建架构涉及的事情如此之多，以至于您会完全忘记某些部分。在产品周期的后期阶段，他们会回来咬你。

我最终决定创建这个清单，您在第一次点击Deploy按钮之前应该考虑这些事项。

因此，没有进一步的构建，这里是您在为产品从头开始构建后端体系结构时应该完成的检查清单。

为你的产品选择正确的语言和框架是很棘手的，这方面没有什么特别的灵丹妙药。我的建议是选择一种你最熟悉的语言，并且知道进出的复杂之处。

话虽如此，这是罕见的，因为很少有人是Javascript忍者，或蟒豹，或任何时髦的名字在那里。

所以选择一种在业界有一些真正良好支持的语言，比如Javascript、Python、Java，或者仅举几例。您可以选择任何一种语言，只需选择最适合您的语言即可。

请记住-您正在构建MVP(最低可行产品)，并且将处于创建概念验证(POC)的过程中。所以尽快把你的产品拿出来吧。你不需要纠结于可能来自于镇上新语言的问题。要避免这些问题，请选择使用更广泛、文档更完善的语言。

最后，您可以在以后进行缩放。如果您正处于进行POC的阶段，只需构建并完成它。但是如果你正在构建一些非常具体的东西，并且有一种语言和一个专门为此而构建的框架，那么你绝对应该选择这种技术。

但大多数情况下，我们试图解决的问题可以通过上述任何一种语言及其各自的框架轻松解决。因此，只要选择一个，就可以启动您的产品。

有很多方法可以对用户进行身份验证和授权。您可以尝试会话令牌、JWT(JSON Web令牌)或OAuth等。每种选择都有自己的利弊。因此，让我们更仔细地看看其中的一些。

JWTs快速且易于实现。这是因为令牌从未存储在系统上的任何位置。它们只是被编码、加密并发送给用户。因此，验证JWT比任何其他方法都要快。

但是，因为它们不存储在系统中，所以您不能在令牌的实际过期时间之前使其过期，这在某些情况下可能是一个问题。

因此，找出每种身份验证系统的优缺点，并选择最适合您需求的一种身份验证系统。我个人更喜欢捷豹突击队(但那是我自己的选择)。

永远不要忘记实现对用户的授权。您不希望登录用户1更改用户2的详细信息。这可能会在您的系统中造成纯粹的混乱。

确定需要授权的端点，并立即实施。您不希望数据库的状态像这样损坏。记住401和403之间的区别。

下面是您在创建身份验证系统时绝对应该考虑的某些端点(我使用JWT在Django中创建了一个)。可以为您的用例添加/删除某些内容，但这些是您应该考虑构建的内容。

很多框架都提供了开箱即用的解决方案，但是在您自己构建它们之前一定要考虑它们。查看Django rest Framework中的AUTHENTICATION_CLASSES和PERMISSION_CLASS以获得进一步。

创建要由数据库中的所有其他模型继承的抽象基模型。

记住“干性原则”--不要重复自己的话。这是软件工程必须遵循的核心原则。

基于上述思考过程，您的数据库中将会有特定的列，这些列将出现在每个表中。因此，最好为它们创建一个抽象类，以便其他模型类可以继承它们。

ID-虽然它没有写在这里，但它是由Django框架自动创建的。但是如果它不在你的教室里，那就在这节课上写下来。它只是一个自动递增的字段，可用作数据库关系中的主键。

CREATED_AT-这表示字段/行插入到表中的时间，它由框架本身填充。您不需要明确设置它。

update_at-这表示上次修改/更新表中的字段/行的时间，并且它也是由框架本身填充的。

DELETED_AT+IS_DELETED-因此这是一个有争议的字段。关于它是否应该在那里，我没有一个确切的答案-因为老实说，互联网上的任何东西都不会被删除。如果填写此字段，则表示该行已从系统中删除(尽管数据仍保留在系统中以供将来参考，并且可以从数据库中取出并存储在备份中)。

UUID-这取决于您是否要将其放入表中。如果您需要将表的主键公开给外部系统，最好是公开这个主键，而不是自动递增的整数字段。你可能想知道为什么.？那么，您为什么要告诉外部系统您的表中有10378个订单呢？但再说一次，这是个人的选择。

出于参与和交易目的，每个产品都需要向用户发送提醒和通知。所以每个产品都需要这个。

您绝对应该考虑构建一个向最终用户提供通知服务(如推送通知、电子邮件和SMS)的微服务。

这应该是一个完全独立的微服务。不要在您的身份验证微服务或应用程序服务(实际的业务逻辑)中构建此服务。

有很多第三方库/服务可以用来为您的应用程序构建它。利用它们，并在此基础上构建它。

注意-有两个发送短信的渠道，交易型和促销型。千万不要在交易渠道上发送促销短信，因为你有可能会被消息灵通、积极进取的用户起诉。

在您的应用程序中配置SMTP客户端的一种简单方法是在您的设置中使用以下内容：

我用Django做了这件事，但是你也可以用你选择的语言和框架做同样的事情。

使用中间件记录生产系统上发生的错误。您的生产系统将不会由坐在那里的人全天候查看应用程序日志来监视，因此您需要一个在中央位置记录这些内部服务器错误的系统。然后你可以每天去检查它们，或者创建一个网络挂钩，这样你就可以在正确的时间得到提醒并照顾它们。

市场上有很多第三方错误记录工具。只要选择适合您要求的任何一种就行了。我主要使用哨兵/空气刹车。

考虑配置WebHook，如上所述。它们将通知您的用户有关错误的信息，例如，您可以在某些闲置通道上发生错误时发布这些错误。然后你可以定期检查这些渠道，并根据它们的严重程度进行整改。

场景-一个用户来到你的支持下，说他们还没有收到他们在你的网站上购买的交易收据。你会怎么做？

如果您已经将应用程序日志记录放入您的系统中，那么不用担心。我这么说是什么意思？举出例子总是比试图用语言来解释要好。所以是这样的：

我已经记录了我即将向提到的email_id发送电子邮件。我可以通过检查系统中是否存在这样的日志来检查应用程序日志，以查看电子邮件是否实际发送到了客户端。确保在您的系统中放置全面的日志，以便您可以跟踪请求的过程。

此外，将异步系统放在适当的位置是一个好主意，该系统将从您的系统中挑选出这样的请求-响应和应用程序日志，并将它们转储到一个中心位置。在那里，它们可以被处理得更容易理解。

场景-您刚刚推出您的服务，并在社交媒体平台上营销产品。一个黑帽黑客发现了，只想玩弄你的系统。所以他们计划对您的系统进行DOS(拒绝服务)攻击。

要解决此问题，您可以在应用程序服务器的负载均衡器上根据各种因素设置速率限制。这将保护DOS攻击，并防止恶意用户攻击您的服务器。

场景-API端点/OTP/VALIDATE采用4位OTP对用户进行身份验证，并返回用于经过身份验证的API的令牌。恶意用户获取您的某个客户端的MOBILE_NUMBER，并开始使用暴力攻击更改IP，即DDOS(分布式拒绝服务)攻击来攻击API端点。速率限制器无法阻止用户，因为IP会随着每次请求而不断变化。

要阻止这种情况，您还可以根据用户对API进行限制。您可以配置特定用户可以向API端点发出多少请求。对于OTP验证，较好的数字是每10分钟5个请求。这将阻止恶意用户对上述API执行暴力DDOS攻击。

场景-当用户在您的应用程序上注册时，您需要向他们发送欢迎电子邮件。前端客户端点击Register API，您在验证后在后端创建用户，这将启动发送欢迎电子邮件的过程。

发送这封欢迎电子邮件需要时间，可能需要几秒钟。但是，您为什么要让移动客户端在这样的过程中停滞不前呢？这可以在后台发生，而不会让用户在注册页面上无缘无故地被卡住。每一秒都是宝贵的，你不希望用户失去那些宝贵的秒。

因此，只需通过异步任务发送电子邮件即可。使用工作器、任务、消息代理和结果后端来执行此操作。

来自Python世界的一个很好的例子是芹菜工人。只需将需要执行的任务放在消息代理(Rabbit MQ/SQS等)中即可。芹菜听了就会把任务交给指定的工人。然后，该工作进程将处理该请求，并将结果放入结果后端，该后端可以是缓存系统/数据库系统。(例如Redis/PostgreSQL)。

您可以使用许多第三方库监视这些任务和队列。芹菜花就是一个很好的例子，它监测着这一切。

场景--您刚刚发布了您的产品，您需要向您的用户发送关于您平台上的新产品的推荐。您将在每个周末根据它们的购买记录发送这些邮件。

使用cron作业可以轻松执行上述任务。它可以很容易地在每个框架中进行配置。需要记住的重要一点是，您不应该将cron作业直接放在服务器的crontab文件中。您应该让框架来处理它。

这是因为出于安全原因，部署工程师/DevOps工程师应该是唯一有权像这样访问系统的人。虽然你不必以这种方式实现它，但从一开始就拥有它是一件好事。

在Django世界中，您可以使用celerybatt来配置使用芹菜工人的cron。

有很多方法可以管理生产服务器中的参数机密。其中一些是：

创建秘密文件并将其存储在私有S3存储桶中，并在部署应用程序期间提取该文件。

在部署应用程序期间设置环境变量中的参数(再次将它们存储在S3中)。

将秘密放入某个秘密管理服务(例如https://aws.amazon.com/secrets-manager/)，)中，并使用它们在您的应用程序中获取秘密。

您可以根据您的舒适度和用例选择这些方法中的任何一种。(您还可以选择为本地、临时和生产环境保留不同的机密文件。)。

这是您从第一天起就绝对应该考虑的事情。您永远不会知道您的业务模型可能改变的频率，并且您需要在您的应用程序中具有向前向后兼容性。因此，您应该对您的API进行版本化，以确保每个人都能顺利运行。

您可以针对不同的版本使用不同的应用程序，并让nginx为您的应用程序处理它。或者，您可以在应用程序本身中进行版本控制，并让应用程序服务器中的路由来处理它。您可以选择任何方法来实现它-要点是从一开始就启用版本控制。

硬更新是指当用户被迫将客户端版本更新到比其移动设备上安装的版本号更高的版本时。

软更新指的是当用户被提示有新版本可用时，如果他们愿意，他们可以将他们的应用程序更新到新版本。

不鼓励硬更新，但有时需要强制执行。无论在哪种情况下，您都应该考虑如何为您的应用程序实现这一点。

您可以通过在Play Store或App Store中实现或配置它来完成此操作。另一种方法是在您的后端应用程序中创建一个API，每次启动移动应用程序时都会点击该API。这将发送两个密钥：HARD_UPDATE-&>TRUE/FALSE和SOFT_UPDATE-&>FALSE，具体取决于用户的版本以及在后端系统中设置的硬更新版本和软更新版本。

存储这些版本的一个好地方是您的缓存(redis/memcache)，您可以在不需要部署应用程序的情况下对其进行动态更改。

情景-在您的项目中工作的实习生之一不够熟练，无法编写产品级代码。他们可能更改了某些内容，可能会破坏项目中的某些关键组件。在这种情况下，您如何确保一切正常呢？

引入持续整合。它将在每次提交时运行链接器和测试用例，如果违反任何规则，它将中断。这将反过来阻止拉入请求进行合并，直到所有线条规则和测试用例都通过为止。拥有它是一件很好的事情，而且从长远来看，它实际上也是有帮助的，所以请记住这一点。

市场上有很多选择。您可以选择自己实现(Jenkins CI/CD)，也可以使用TravisCI、CircleCI等来实现。

为您的应用程序创建一个Dockerfile和docker-compose.yml，这样每个人都可以从一开始就使用Docker运行应用程序。使用这种方法的主要原因之一是在您的本地/暂存/生产环境中保持一致性，这样开发人员就不会再这样说了：

从第一天开始就使用它并不困难。一开始，只需在您的本地环境中使用Docker，这样您的应用程序的安装就可以真正流畅。但请记住，无论是否有Docker投入生产，您都可以运行它。

如果您想要监视应用程序的API、事务、数据库连接等，则必须使用应用程序监视工具。

场景-您的cron服务器的硬盘几乎已满，无法运行cron作业。因为它在光盘上找不到空间，所以您的cron没有运行。那么，当这种情况发生时，您如何才能得到通知呢？

有很多APM工具可以用来监控这一点。您可以根据需要通知您的时间配置它们。当您的系统发生这种混乱时，您将在您选择的介质上收到通知-相信我，这种情况一直都在发生。所以最好做好准备。新的遗迹是个不错的选择。

ElasticSearch是一个基于Lucene库的搜索引擎。它提供了一个分布式的、支持多租户的全文搜索引擎，具有HTTP web界面和无模式的JSON文档。ElasticSearch是用Java开发的。

一开始，您会尝试使用传统的数据库查询来获取客户端应用程序搜索栏中的结果。为什么？因为这很容易。

但是传统的数据库并不适用于这种高性能的查询。找出将您的搜索迁移到ElasticSearch的最佳时机，并将数据管道引入您的系统。它为弹性搜索提供数据，然后将搜索从ElasticSearch连接到应用服务器。

你绝对应该这么做--这是必备的。在您的生产服务器中设置防火墙，并关闭除用于API(HTTPS连接)的所有端口之外的所有端口。使用反向代理Web服务器(如Nginx或Apache)路由API端点。除Nginx允许的端口外，其他任何端口都不能对外访问。

上面提到的几点都是基于我自己的喜好，我多年来发展出来的。这里和那里会有细微的差异，但概念保持不变。

最后，我们做这一切是为了在你想出这个主意后，尽快让一个从头开始建立的流畅的系统投入生产。

我试着把这些年学到的知识都写下来，可能有几处是错的。如果您认为您可以提供更好的信息，请随时发表意见。如果您认为这对您有帮助，请一如既往地与我们分享。

免费学习编码。FreeCodeCamp的开源课程已经帮助超过4万人找到了开发人员的工作。开始