开发运维视角下，影响软件高可扩展性的6个因素( 二 ) 作者|GeshanManandhar译者

使用客户端会话替换服务器端会话
另一个经典例子是不在web应用使用服务端会话，而是使用客户端cookie 。
您可以轻松地用使用类似JsonWebToken（JWT）的方案替换服务器端会话来进行身份验证和授权。
JWTs可以在每个请求中作为header或者cookie的一部分被轻松的从客户端传给服务端。因为服务器可以像牲口而非宠物一样工作，扩展软件变得非常容易。如果您必须使用会话，那么使用类似Redis的数据库而不要保存在本地文件系统，以保证服务器可以轻松的被替换。
这里的关键点是，不要留恋您的服务器，它们应该是一次性并根据负载弹性配置的。这样我们就可以通过编写无状态软件来实现易扩展和高可用成为可能。
3运维视角的软件可扩展性关于运维和平台这两个表述，我指的是在哪里以什么方式部署和运行软件，另外还涵盖这些系统的架构以及它们如何交互。
软件部署的位置是至关重要的。
如果您的用户在悉尼，而软件部署在欧洲，它将有很大的网络延迟。
类似的，如果组件布局不好或选择不当都将产生负面影响。让我们看一下在运维层面对软件可扩展性有至关重要影响的因素。
垂直扩展与水平扩展这是一个关于把服务器类比成牲口还是宠物的延伸讨论。想象一下，您正在管理一个相当受欢迎的电子商务网站，该网站每天约有500个订单和5万个独立访问用户。您有一个规格接近AmazonEC2m5.4xlarge的大型web服务器，它有16核CPU以及64GB的大内存。我们假设在上面运行WooCommerce商店，包括网站服务和MySQL数据库都运行在这同一台服务器上。
现在，距离黑色星期五只有3个月了，公司打算做一个大规模的电视广告推广，预计流量在节日期间有5-7倍的增加。管理层将在广告方面投入大量资金，在这4-5天内网站不能瘫痪。
预计该网站在这3-4天内，每天将有30万以上的独立用户访问和3千以上的订单。
您现在有两个选项来扩展应用程序，要么垂直扩展（scale-up），要么水平扩展（scale-out）。
垂直扩展（Scale-Up）
如果选择垂直扩展，那么需要增加更多的硬件资源来解决这个问题。
您可以改用一台EC2m5.24xlarge的机器，它拥有96核CPU和384GB内存。
CPU和内存是老机器的6倍，所以理论上它应该足以支撑。
但有3个重要问题，首先您将需要一点时间停机来升级硬件，其次也是最重要的原因是这台机器会造成单点故障。考虑到网站负载，数据库很可能由于某个问题而崩溃。稍后如果流量没有预期的那么大，您还将为避免过度浪费资源进行收缩操作。
水平扩展（Scale-Out）
另一种选择是水平扩展，您将尝试获得许多较小的EC2实例，比如8-50个t3.mediums实例。
每个实例将拥有2核CPU和4GB的内存。因此，一组包括50个t3.mediums实例的集群可以为您提供总共100核CPU和200GB内存。要在这些新的EC2实例集群之间均匀分配负载，可以使用Amazon应用程序负载均衡器。
为了使应用程序更具可扩展性，您可以使用具有32个核CPU和128GB内存的AmazonRDSdb.m5.8xlarge实例。根据需要，您还可以配置备份。这时您有50台服务器可以使用，假如有3台坏了可以马上换上3台新的。
如果负载偏低只有3个实例在运行，当流量激增时分分钟就可以增加20个。
在打折季结束后，您可以将DB缩放到db.m5.large ，这足以满足每天500个订单的情况。
考虑到这点很重要，让我们在下面可视化地解释一下。

文章图片

文章图片
这是Docker和Kubernetes的一部分亮点，您可以将工作任务打包进轻量级的容器，而Kubernetes可以管理水平扩展和滚动部署这些容器。这些年Docker已经改变了我们工程师的工作方式。
这里要提到的一点是扩展关系数据库是非常困难的。即使有了分片之类的技术后，如果你不清楚自己在做什么，垂直扩展关系数据库会比水平扩展更容易些。这里的Amazon就是一个例子，同样的概念可以应用于其他任何主要的云供应商，比如谷歌云或Azure 。这就引出了我要讲的下个要点， NoSQL数据库的使用。
使用NoSQL提高软件可扩展性在上面的例子中，如果您的在线商店网站上有20个人，可以使用关系数据库提供服务。对于每个用户的每个请求，应用程序都会到达关系数据库，虽然慢，但不会造成严重后果。现在想象120个用户同时在线，性能很可能已经很明显的严重下降，我们可以看到基于预分配的数据库开始出现一些数据库连接的问题。