【.com快译】以前我们很容易经历一系列流程：取出裸机服务器，安装所有必要的软件，添加所有应用代码，在其上加载数据，部署单体应用程序。由于所有组件都集中在一台服务器上，因此这种应用程序不仅可以处理大流量，而且非常易于管理和部署。然而，此类应用程序的一个大问题是效率低下。例如，您必须提前估计峰值负载，以便分配性能充分的服务器。但是这样配置的服务器在正常负载下资源会闲置，轻负载下甚至会造成很大的浪费。此外，我们可能还需要通过痛苦的手动操作来手动扩展服务器的资源。而如果某个组件需要的资源比服务器本身还多，则必须关闭整机进行升级，这将不可避免地影响到所有其他组件。因此，裸机服务器确实还是有其独特的适用场景，只是逐渐被新的微服务架构所取代。什么是微服务架构？微服务架构是一种软件开发技术，它将应用程序构建为松耦合服务的集合。这些具有轻量级协议特性的细粒度服务，不仅提高了应用程序的模块化，而且便于理解、开发和测试。小型自治团队使用它们来独立开发、部署和并行扩展他们的服务。此外，基于微服务的架构还可以支持持续交付和部署（来源：维基百科，https://en.wikipedia.org/wiki/Microservices）。因此，不再局限于将所有代码、数据库和数据资产部署在一台服务器上，而是将每组代码分成不同的组，彼此独立运行。因此，我们可以通过设置特定的存储区域，让一些代码只负责图片的上传、操作和保存；我们也可以通过创建特定的数据库，让一些代码只负责检查和创建会话。或者，您可以有一个特定的代码块来处理新的用户帖子，以及另一个代码块（或服务）来检查不当评论。一个数据库可以用来存储各种评论，而另一个库可以用来按关键字搜索。那么，微服务有哪些实际好处呢？·首先，每个微服务都可以根据使用情况按比例扩展其容量，以节省宝贵的服务资源。其次，我们可以更好地将开发人员与负责数据库的人员、编写后端代码的人员以及UI/UX人员等分开。·此外，由于每个服务都能够独立工作，一个组件上的负载不会影响另一个组件。同样，一个组件的升级不需要涉及另一个组件的拆分。可以看出，每个组件都可以获得更高的正常运行时间。微服务架构的局限凡事有利有弊，微服务架构的主要缺点之一就是应用整体正常运行时间的保证。当我们将整个应用程序分散到单个微服务中时，单个组件的可靠性会增加，但代价是将不确定性引入应用程序的整体可靠性。在单个裸机应用中，无论是网络、硬盘、内存还是其他方面出现问题，都会导致应用整体中断。因此，如果供应商向您承诺99.5%的正常运行时间，您只需担心在这99.5%的基础上进行改进。但是，如果您使用的是微服务架构，每个组件都会有自己的正常运行时间基准。例如，如果您的应用程序使用10个服务，并且每个服务的总体正常运行时间比率为99.5%，则总体正常运行时间比率为99.5%的10次方=95.0%。这是否意味着微服务架构不好？不必要。这只是意味着除了收获微服务的好处之外，开发人员还需要采取额外的步骤来保护他们的应用程序并减少潜在的停机时间。有趣的是，我们可以在这里介绍另一个微服务——阿里云的消息服务（参见https://www.alibabacloud.com/product/message-service）。阿里云的消息服务是什么？阿里云的消息服务是一种分布式的消息队列和通知服务。它支持并发操作并促进应用程序和解耦系统之间的消息传输。阿里云的消息服务使用户能够通过在分布式应用程序之间传递数据来实现各种复杂的任务，进而构建解耦和容错的应用程序。消息传递如何提高正常运行时间？为了更好地理解消息传递如何提高可靠性，让我们讨论一个典型的群聊应用程序。假设你已经建立了一个类似球迷的群聊应用——SportsApp，其中包含各种聊天群，例如：切尔西、巴塞罗那、皇家马德里、拜仁慕尼黑和曼联等热门足球俱乐部。任何人都可以向任何群组发帖，并可以订阅他们最喜欢的俱乐部群组，以便收到其他粉丝发布的消息通知。显然，您应该在开发此类应用程序时考虑到可伸缩性。通过持续监控其增长，您还可以过滤掉各种不当新闻言论和图片，并提供消息搜索功能。因此，为了满足这些需求，您为每个功能提供了一系列的云服务。其最终的系统架构如下图所示：在上述案例设置中，当用户想要向某个群组发布新消息时，体育App的后台会收到请求，然后传递给各个微服务，最后通知用户是否发送成功。具体过程如下：首先，后台检查用户是否有向特定群组发帖的权限，同时过滤掉不规范的HTML标签或其他危险参数的输入。然后，应用程序使用一些人工智能相关的服务来检查消息的合规性，如果通过检查，则继续将消息保存到云数据库中。然后，该程序将消息传递给搜索优化的数据存储服务，例如Elasticsearch。SportsApp可以决定添加一项单独的数据分析服务，以分析诸如哪些俱乐部名称被提及最多等特征。此外，开发者还可以为应用添加监控，了解请求是如何执行的。最后，SportsApp将提醒所有成员这条新消息已发布到目标组。正如我们所看到的，整个过程可能有点冗长，即使它们在几毫秒内完成，整个消息传输链仍然包含许多潜在的故障点。而且，一旦链上某个服务出现故障，整个请求传递过程就会出错。我们再回顾一下上面请求检查的业务逻辑。事实上，对于一个发布消息的用户来说，他既不关心后台进行的身份验证，也不关心消息的合规性，更不用说消息是如何存储的，后台如何保证每个组成员可以接收新消息。他只需要关心自己的消息最终能否发布到目标群体即可。因此，让我们通过使用消息服务来调整我们的技术堆栈以满足此类需求。新技术栈对应的系统架构如下图所示：在上面的架构中，当用户发布一条新消息时，我们需要做的就是传递给消息服务。如果成功，消息将返回给用户并附上成功回执。整个过程仅需几毫秒，对于应用端和用户端来说都是非常好的体验。在单独的请求中，应用服务会将相应的信任凭证和参数返回给体育后台服务器，而不是用户。在此过程中，如果出现任何错误，我们只需要事先设置好标准的错误响应码即可，比如“503：服务不可用”。同时，消息服务会反复重试请求，直到发送成功，否则默认7天后超时。当然，您不必就此打住。通过使用消息服务，您可以进一步解决诸如：权限检查或消息合规性检查等问题。通过这种方式，您可以逐步提高您的应用程序使用的各种微服务的可靠性。原标题：提高微服务的可靠性，作者：DonOmondi
