单击上面的“朱小博博客”，然后选择“设置为星”

回复“ 666”以获取新汇编的1000+GB信息

1。二阶提交

通常，当数据库中的数据更改时，它将写入本地服务器的内存和磁盘。但是，当数据库是群集或分布式系统时，提交不仅会在本地发生，而且会发生。二阶提交意味着必须等待远程服务确认。然后由于网络和其他延迟问题，此类提交比独立数据库的提交要慢得多。

主奴隶同步复制也存在这样的问题，因此该解决方案是半同步的（仅在半同步中存在的功能 - :. 5.半同步只需要等待成功的日志响应，并且不需要。需要等待完成真正提交的内容），这实际上是二阶提交的妥协。

2。串行处理

当客户在等待超市带有10个收银机的超市时，这并行起作用。如果有9个出纳员在午餐上休息，只有1个收银机已开放，它将成为序列号。突然，由于现金寄存器问题，超市将排队队列，这将使客户感到非常沮丧。

Web应用程序必须不惜一切代价避免串行，典型的串行（例如分布式锁）。否则，会有一个地方将串行处理成为整个系统中的瓶颈。

3。内存不足

记忆对于每一层都非常重要。什么是最合适的缓存场所？接下来，让我们给您一些栗子。

浏览器

在您意识到浏览器获取直接从Web服务器呈现页面所需的数据之前，浏览器缓存似乎无法触及。因此，如果页面中包含的对象的到期时间很长，则浏览器可以缓存它们而无需反复爬网。它不仅具有更快，更好的用户体验，而且还降低了服务器端的压力。

页缓存

页面缓存（不在操作系统级别）需要技术组件，例如（和使用此技术）。它不能像这样处理复杂的页面，但是它可以比它更好地处理简单页面，因此通常将其部署在前面以首先处理简单的页面。

对象缓存

通常，使用对象缓存（或）来处理，将对象序列化为例如JSON，然后将其保存到其中。在访问数据库之前，我们的应用程序首次访问以查看我们是否需要对象。如果有的话，从它们获得对象的速度是数据库的数十个甚至数百倍。这可以提高服务响应速度并返回用户眨眼间要求的所有数据，从而使用户体验更好。

4。监控和指标不足

监视应该是一个基本的事情，您无法想象没有它。但是，某些公司和项目只是没有或不足，没有足够的监控，并且错过了一些服务器或关键组件。

随着时间的流逝，收集有关系统和服务器级数据以及应用程序和业务级别可用性的数据同样重要。

5。日志不足

日志和监视密切相关，尤其是在找到问题或调试时，您需要需要更多日志。无论是服务器系统日志，日志，缓存日志等，都必须在日志滚动以及历史日志备份或清洁方面做得很好。

6。数据库单点

您的数据库应该至少具有一个，其优势是，当出现问题时，您可以更快地恢复数据库以提供服务。即使您不承受阅读的压力，也应该有冷备份。

7.将数据库视为队列

数据库擅长存储关系表数据。不幸的是，它不是很擅长作为队列。尽管如此，许多开发人员仍然有一些不良的用法习惯，例如：您的应用程序有一些工作任务表，也许还有一个状态列，并且此列的值包括以下内容：init，,,,等。 ，然后您将使用数据库表作为排队。

该解决方案最终由于锁定竞争，扫描和投票而遇到可伸缩性问题，以查找更多可执行的任务，并且此状态列并不适合创建索引。如果您有队列要求，建议使用或使用。

8。使用数据库全文搜索

搜索是任何应用程序的非常重要的功能。尽管有一个全文检索功能，但其前提是该表必须是引擎。但是，该表没有交易特征，其性能和经验也很差。

成熟的解决方案将通过Solr和Solr等专业搜索服务制定。此外，这些专业的搜索服务客户端支持大量语言，并且访问速度也非常快。弹性和弹性能力非常好。

9。Orm

ORM帮助快速原型制作，并允许不擅长SQL的开发人员读取和编写数据库。它们更快，更干净，并提供更快的功能交付。

然后，当DBA发现一个缓存的SQL并要求您的团队修复它时，如果您使用ORM框架，您会发现故障排除问题非常困难。但是，对于开发人员而言，故障排除和优化SQL通常是这样做的。如果您的项目使用ORM，它将带来巨大的技术债务，而替代成本也很高。因此，建议该项目使用这样的框架。

10。没有仪表板

如果汽车没有仪表板，您将无法开车。同样，如果您的应用程序没有仪表板，它也会带来很多障碍。应用仪表板可以揭示有关应用程序内部工作的信息。他们记录时间并提供有关应用程序需要多长时间的反馈。

New（）是一个非常流行的Web服务仪表板解决方案，它提供了一个可吸引所有人的视觉仪表板 - 项目经理，开发人员，运营团队，甚至业务部门都可以查看并查看图表中发生了什么。

11。没有代码存储库或版本控制

虽然今天非常罕见。简而言之，在这方面，您的公司不得成为“杰出”公司。它必须将代码放入代码存储库中。强烈建议使用GIT+组合管理。

如果您不使用版本控制和代码存储库，那么随着您的项目变得越来越复杂，您将欠更多的技术债务，最终将导致整个迭代中的艰难一步。

12。单点问题

如果您的数据只有一个实例数据库，则这是一个问题点。如果您的所有服务都部署在一台服务器或磁盘上，这也是一个问题点。

这些单点问题必须不惜一切代价完全消除。此外，很难意识到系统的单点。例如，依靠单个云供应商实际上是一个问题点。因为如果您的服务全部在AWS上，那么当AWS出现问题时，您的服务将完全不可用。当AWS失败时，避免了此问题。有关更多信息，请单击链接：。

13。缺少预览模式

如果您尝试对头条新闻发表评论，或发送有关微信的时刻更新。您可能会收到这样的消息：“对不起，请稍后再试！”。或者，您只能在上预览产品，但您不能下订单。

这种现象意味着该应用程序允许您阅读，但不允许您写作。这可能是因为图书馆倒塌了，但是图书馆仍然还活着。我们的系统需要具有此功能。当库倒下时，它可以正常处理读取操作，但是写操作会受到暂时影响。

14.缺乏沟通

在这里谈论交流可能有些奇怪。但是，强大的沟通渠道非常必要，团队成员必须知道遇到麻烦时要寻找的人。良好的沟通需要信心和知识渊博的领导，以及开放的倾听和改进。

15。缺乏文档

文档发生在Web应用程序的许多层中，例如前端，UI，后端，操作和维护等。开发人员需要设计文档，以提供有关查看代码的落后者的提示和参考。操作团队需要在配置文件中添加注释，以便在事情中断时提供更改历史记录和见解。业务流程和关系应记录在公司的Wiki中，以帮助人们找到解决自己问题的解决方案。

文档在各个层面上都非常有帮助，写文档是每个人都应该拥有的习惯。

16。缺失钻

故障演习总是来回推动。团队可能会说：“我们有备份，我们可以生活在这件事中。”没错，直到他们尝试基于备份恢复并发现它们不完整，并且可能丢失了一些配置文件或关键数据之前，他们才是。

故障演习可以帮助团队在真正需要的情况下完成该动作。贵公司应将其视为运营团队日常工作的一部分，每年几次恢复整个申请。并且使用云服务器将使这更容易。在此过程中，您将了解需要多长时间，艰难的步骤在哪里以及要注意什么。因此，当错真正出现时，您可以冷静地处理它！

17。鲁ck行为

您骑着一匹快马骑行，用枪走进沙龙。您认为您会结交朋友吗？不，你只是吓到所有人。信心很好，但是最好与团队合作，团队的智慧比任何人都强。

团队需要以托管方式传达正在发生变化，交流的内容，并且应该制定对任何事故等做出回应的计划。而且总是有一个计划。做事时，有一种方法可以退缩。您必须知道哪些命令具有破坏性，哪些命令无法撤销。

18。越来越多的技术债务

随着多年来应用程序的不断增长，团队可能会花费越来越多的时间来维持历史法规并解决历史问题。因此，他们没有太多时间投资新功能。如果您发现技术债务正在增加，则可能是时候磨牙并重新分配牙齿了。重构需要时间，而重构将不会带来直接的结果，例如开发新功能和满足客户需求，但从长远来看，这是非常值得的。

本文翻译回：