适用于更具弹性的应用程序的现代配方

Kubernetes ， Docker和微服务就是现在创建新应用程序软件的方式。 对于新的应用程序，通常在您的前端与移动应用程序的后端的请求层之间有一个图形 。 但是，此后，仍然存在一个Web circa-2007请求，该请求通过数个防火墙连接到某种应用程序服务器和数据库的良好，丰富，潜在的连接，通过后端向后端发出请求。

如果亚马逊 再次 阻塞互联网 ...或其他人阻塞AWS怎么办？ 如果您的移动应用程序或Intranet是通过经典方式构建的，那么您将大失所望！ 提示400和500错误！ 如果您只是要在办公室内推送电子表格，那么没关系-减轻负担。 但是，如果您是一家为心脏病患者服务的药店，或者是在“超级碗”周日送达披萨的地方，那么很多人会深切关注。

[ DevSecOps：如何将安全性引入敏捷开发和CI / CD ]

幸运的是，随着新的可用方法和新的创新，应用程序弹性和高可用性方面的某些事情正在发生变化。

迈向弹性客户端应用程序

提高弹性的一种方法是将整个应用程序服务器和数据库放在每个位置（许多公司都这样做）。 另一个是使应用程序和移动应用程序更具弹性。 这意味着它应该能够在没有后端数据库或应用程序服务器的情况下（至少在降低的服务级别上）运行。

例如，即使您在两个不同的商店购买药物，像CVS或Walgreens这样的药房链也可以检测到药物相互作用或用药过量的风险。 如果架构正确，那么即使网络中断，这些店内应用程序也可以运行。 在“网络中断”的情况下，虽然可以指导某些药剂师针对相互作用和剂量给出更具体的警告，但某些药物不能配药但心脏药物可以配药。

这通常需要本地化的数据库和后端数据库的某种边缘同步网关。 您不能只调用远程API。 您需要在前端将它们作为本地代理实现。 要正确执行此操作，您应该首先在“网络中断”方案中进行编码。 这可能比您想象的要容易，因为您可以编写移动应用程序而无需参考后端（至少在最初阶段）。 （完全公开：我为Couchbase工作，该公司生产包括Sync Gateway在内的开源NoSQL数据库产品。）

这不仅适用于移动应用程序。 胖客户端应用程序（例如Java的Swing或Microsoft的WPF或UWP）也可以使用此技术。 在网络和移动设备时代，胖客户端仍然占有一席之地。 想一想您最喜欢的披萨交付链。 显然，每个商店都不应要求员工配备DBA（尽管送货司机/ DBA具有一定的吸引力）。 帕帕·约翰（Papa John's）或必胜客（Pizza Hut）是否真的需要每个商店中的应用程序服务器才能运行Web应用程序？

但是，某些地方可以负担得起远程位置的应用服务器。 有时甚至可能是一个区域性云区域（尽管有人可能认为数据库也应位于同一位置并进行复制）。 对于各种延迟问题，游轮或远程实验室可能在船上装有应用程序服务器甚至数据库。 尽管存在本地数据库，但您可以使用WAN复制而不是同步网关，但适用相同的一般原则。 如果真的不能选择打电话到云，您可能还会得到批处理作业。

[ 也在InfoWorld上：如何将测试自动化与敏捷和devop结合使用 ]

迈向弹性服务器应用

并不是很多年前，我是一名可伸缩性和性能顾问。 我要做的第一件事是删除所有对“ localhost”的远程调用。 我这样做的速度很慢，因为当您每小时收取300美元的费用时，一定不要在第一小时内解决问题，这一点很重要。 第二件事是切换打到父级并延迟加载子级（n + 1）的所有查询。 第三件事是修复缓存。

随着体系结构变得更加面向服务和基于微服务，出现了另一类问题-一些服务的使用比其他服务更加不均衡。 颠覆的源头通常是数据库，尽管有时它实际上仅仅是服务本身。 有时候，这甚至是一种攻击，因为当您在海滩上建造漂亮而精致的沙堡时，总是会有一个孩子来踢它。 避免这种情况需要几层保护。 可以将它们想象成栅栏，护城河和一些鳄鱼。 那会显示一点。

摇动的另一种形式是n + 1问题的服务版本。 如果您要对服务进行大量的获取和拒绝，则可能会导致很多单独的，细粒度的呼叫。 这些都需要以某种方式收集。 虽然让客户做到这一点是一个好主意，但依靠客户去做任何事情（例如不要意外地踢过您的沙堡）是一个坏主意。

第一种保护是使用基于消息的异步反应式编程风格。 与其将REST呼叫从一个地方转移到另一个地方，不如将呼叫放在一个队列中，然后让其他事物“响应”该呼叫。 本质上，您正在传递状态更改。 这类似于旧的企业服务总线方法。

第二种保护是使用API​​网关 （示例包括Kong和Apigee ）。 API网关将请求路由到正确的服务，甚至可以将请求“组成”到一个远程调用中。 这也有助于防止客户端暴露于您的微服务中。

第三种保护是使用服务网格 （示例包括Istio和Red Hat OpenShift服务网格 ）。 当服务彼此通信时，故障可能会级联。 而且，将通信逻辑复制到每个服务中是浪费的。 当服务网格和API网关结合在一起，并且部署了正确的操作工具时，可以在大型，复杂，使用频繁的应用程序中监视，扩展和部署服务。

[ 同样在InfoWorld上：启动devops程序的3种方法 ]

边缘计算，无边计算和雾计算

最安全的数据在您的脑海中。 第二个最安全，可访问且最低延迟的数据在您的掌中被加密。 如今的设备与您可能记得或可能不记得的DOS，Novell，Windows 3.11，Windows NT，Windows 2000或Windows XP桌面相距甚远。 默认情况下，智能手机不会使用从未经批准的来源下载的外来软件。 与安装桌面应用程序相比，用户更有可能使用Web应用程序。 许多大型组织很难安装经过批准的软件。 这些不是愚蠢的终端，但是它们也不是用户管理的混乱中心。

边缘设备和软件使您的应用程序可以将其某些数据和计算需求转移到地理位置更接近客户端或移动应用程序的服务器上。 有时这些使用“云”或小型的区域性数据中心。 研究表明，边缘计算可提高部署在云中的应用程序的性能和规模。

5G网络的出现有望支持网络上更多的无线设备。 有人认为这是雾计算的机会， 雾计算是向最终用户提供计算，存储和服务的边缘层。 基本上，您没有大型的边缘云，而是拥有一个大型的区域云，该云由较小的，分布在地理位置上更近的分布式设备组成。

[ 通过InfoWorld的App Dev Report新闻通讯了解软件开发中的热门话题 ]

过去，这是无边缘计算的想法。 我们的智能手机和其他设备本身已经具备了强大的功能。 为什么不利用分布在网络上的所有潜在计算能力进行处理？ 这项技术还不存在，我们仍然更喜欢集中式数据库，因为它们更易于管理。 但是，人们看到了诸如区块链之类的技术，并问我们在找到一种集中管理它们的方法时是否不能安全地分发数据，处理和应用程序。

尽管并非完全相同，但您可以在Apple和Google如何使用联合学习在智能手机上分发共享机器学习模型的培训中看到其早期版本。 不仅网络是计算机 ，数据库也将是我们的未来。

From: https://www.infoworld.com/article/3521036/modern-recipes-for-more-resilient-applications.html