Web应用托管服务（Web+）隐藏的十个上云最佳姿势

随着云计算浪潮的推进，技术架构云化已经成为大势所趋。特别是最近由CNCF推动的云原生概念，将符合云原生标准的各种开源技术方案推向了前所未有的高度。在这一波浪潮的推动下，越来越多的企业开始了自身的数字化征程，逐步将自己的IT基础设施往云上迁移。Web应用托管服务（Web+） 正是在这一波浪潮下应运而生的黑科技产品——以应用为中心，为应用编排所需的云资源，并将中间件团队支持近千家企业客户上云时遇到各类问题的解决办法，形成一套最佳实践沉淀到这个产品中呈现给大家。这篇文章，就将逐一向大家揭秘隐藏在这个产品背后的十个最佳实践。

产品体验地址：点击，永久免费

基础设施即代码（Infrastructure As Code）

基础设施即代码，简言之就是用代码或配置文件来声明应用系统使用的基础设施资源。云计算技术发展到现在，基础设施即服务（IaaS）能力已经变得非常成熟了，其能托管的底层资源也越来越丰富，从计算资源、网络资源、存储资源到大数据资源、区块链资源以及人工智能资源等等，都可以作为基础设施被按需取用。因此也产生一个问题，就是云资源的使用变得越来越复杂，门槛越来越高，一个复杂一点的业务系统动辄集成十几个云计算产品是非常常见的情况。不仅如此，这些资源应该如何被编排与使用，有时需要富有云架构管理经验的人员辅助才能得以顺畅实施。这些都严重加剧了云计算能力向中小用户渗透的难度，导致发展受阻。而基础设施即代码可以非常优雅的解决这个问题，用户不再需要手动管理基础设施，而只需要以代码的方式提交对资源的声明，便可由系统自动完成对资源的创建、编排与配置，极大降低了云产品的使用难度。而且一套符合标准的基础设施即代码文档是可以被分发及复用的，这有助于打破云厂商之间的产品界限，促进计算技术的革新与发展。

省钱之道：预留实例，包年的优惠按量的使用

提到云计算，我们都会想到其低廉的价格和按需使用的特性，因此按量付费也理应成为云计算产品的主流付费方式。设想倘若用户购买了一台以包年包月方式计费的云产品，他该如何才能做到按需使用呢？尤其是遇到弹性伸缩这种场景——系统所使用的计算资源会随着访问量的大小而自动扩容或缩容，包年包月的付费方式显然没办法如此灵活，而且也与云计算倡导的按需取用的理念相违背。但是，包年包月的付费方式显然也有其吸引人的一面，那便是价格优势——通常来说都会比按量付费要便宜。这也非常容易解释，把包年包月当作是按量付费的一种批发形式就不难理解其价格差异了。那么是否存在一种付费方式，既不违背按需取用的云计算精神，又能够帮助用户节约成本呢？这便是预留实例。我们可以把预留实例想象成游戏机室使用的游戏代币，买得越多越便宜。而想要玩某一台游戏机的时候，仅需支付若干枚代币即可。预留实例也是这个原理。用户需要购买1年或更长时间的预留实例以获得优惠，而这个预留实例可以用来抵扣按量付费产品产生的费用，也就是说如果使用了一个小时，那么就会从预留实例中扣除一个小时的费用，直到消耗完毕。

合理使用配置

在The Twelve-Factor App的第三部分就提到了与配置有关的原则。本文所说的配置可以涵盖非常广泛的概念，除了狭隘意义上的应用程序配置文件，上文中提到的基础设施即服务的有关文档也可以属于配置的一部分。

配置与代码分离。代码作为应用系统的构建来源，自然与产出物是密不可分的。我们通常将应用程序或软件包称作为“构件”也具有这层含义——即通过代码编译而形成的组件。从版本管理的角度来看，代码可以被认为是具有不可变属性的，代码的变更通常意味着版本的升级。如果代码变更与版本升级之间脱离关系，必然会造成软件版本的混乱，给交付、部署和运维带来困难。而配置却不尽相同，虽然各种最佳实践也是建议将配置以版本化的方式来管理，但是配置与代码分离管理，是更好的解决方案。因为配置的变更与代码的变更不一定是同步的，切换某台主机的IP地址，更改某个数据库连接池大小等等，这些都不依赖代码的变更，也就是说在同一个版本的软件包上可以应用不同的配置。在微服务领域，系统配置通常会由一个独立的配置中心服务来维护，其负责管理配置变更、配置版本以及配置推送，不管应用部署的是哪个版本，只要需求和环境不发生变更，配置就可以始终复用。

配置与环境共存。虽然配置不依赖代码而存在，但其与环境的关系却是非常密切的。举个简单的例子，一个应用系统从开发到上线通常都会存在开发环境、测试环境、预发环境以及线上环境等，而每个环境的配置可能都是不同的。例如测试环境无需高可用，性能也不用特别优化，基本上满足系统能够运行起来就够了。而线上环境就需要保证高可用、高性能与稳定性，自然环境配置也不相同。倘若我们把系统环境中的所有配置都固化下来，那么这份配置与环境就是完全映射的了，即便环境被销毁，我们也可以通过这个配置重新启动一套一模一样的环境，这就是配置与环境共存的含义。

做好数据安全与审计

安全是个很大的话题，通常来说没有绝对意义上的安全，也没有单方面的安全责任，只要有互联网存在安全就是永远不能回避的问题。从功能设计到代码实现、从系统架构到部署实施、从底层资源到上层业务、从数据存储到业务流程，每个环节都可能会有被侵入的风险，因此安全需要是客户与厂商共建的系统性能力。但是不管怎么样，有两件最基础的事情，我们可以先做好：1）做好数据安全；2）做好安全审计；以云产品为例子，请见下图：

首先：数据安全是用户最为担心的问题，我们建议从上传开始，不用流转太多的服务，就利用云存储的能力，直接到达您的“家里”。
其次：所有需要针对机器下发的指令，建议走云厂商提供的正规通道，这么做的一个很重要的理由就是可以做到可以控制权限，也可以做到审计。

使用 ECS 实例访问角色

承上文，之所以能够实现数据链路的完全隔离，还要得益于实例访问角色的支持。简单来说，运行在主机实例上的应用默认是没有办法直接访问用户的其他资源的（图中主机实例从共享存储中读取数据的链路）。想要实现此目标的办法有两种。一种是将用户账号的AK/SK配置到应用中，让应用以该账号的权限访问用户资源。这种办法的优势就是简单易用，仅需生成并配置AK/SK，再通过API进行访问即可，几乎没有什么额外的开发成本。但其劣势也是非常明显的，即该AK/SK存在泄漏的风险，一旦泄漏，非法用户便可以使用该组AK/SK访问用户的任何授权资源，结果将非常危险。另一种办法就是通过实例访问角色，将访问用户资源的权限授权给主机实例的服务账号，再由该账号访问用户的资源，这种机制从以下三点保证了安全性：

• 时效性：访问云资源时，可根据一个临时令牌是生成一对临时的AK/SK，窃取访问权限的难度倍增，且即便盗用成功，也仅在某一段时间内可用，过期后即失效。
• 隔离性：您可以授予不同的主机实例，从而做到实例级别的身份隔离。即使黑客攻破了其中一台，对其他主机也不会产生影响。这样做的好处也体现在无需额外配置AK/SK，直接从主机实例上就能获取对应的访问凭证。
• 可管控：可以随时在RAM控制台上撤销访问权限，或者调整其权限，从而做到对实例级别的精确控制。

计算与存储分离

计算与存储分离，即是一种架构理念的革新，也是一种运维习惯的转变。在架构上，我们推荐您尽量将服务用的计算集群与数据存储用的存储集群进行隔离。这样一来，我们针对计算集群只需要做简单的扩容，就能应对特定场景下流量的突增；而同时，针对存储集群做针对性保护。在运维上，计算集群与存储集群也需要分开部署，因为很多情况下不是同一组人员在维护计算与存储集群。
在云上，常用的数据服务如：缓存、日志、数据库、分布式存储和云盘等，已经能够满足绝大部分的业务需要了，而针对特定场景（如大数据和NoSQL等）云厂商也提供了相应的解决方案。这些成熟的方案，可以为您解决部署、运维、数据同步和备份等诸多问题。

水平扩容优于垂直扩容

云计算带来的资源革命，主要体现在对待资源的申请方式上，即：从之前的什么都规划好到按需申请、按量访问，尽量利用云的弹性能力获得最高的利用率。所以在云时代，我们推荐是需要资源的时候就按需申请，不需要的时候就归还回去。这意味着，不推荐一上来就使用很大规格的机器，而是先申请一台较小规模的，等到需要的时候再扩容。由多台小规格机器组成的服务集群，比单一一台大规格的机器，既方便伸缩，也能够获取更多资源（如：带宽和磁盘等），更重要的是它会让您的服务天然具有高可用的能力。

尽量复用 SLB

每一个服务需要对外提供服务时，如果是一个集群，需要以统一的出口对外，这个时候需要用到SLB的能力。阿里云的SLB目前由统一的集群负责，可以实现四层、七层的转发。随着您的应用个数或者对外暴露的服务越来越多，可以选择复用SLB——即选择同一个SLB ，使用域名或者URL的方式，将流量转发到不同的服务器组，如下图所示：

这样做有两个好处：
1、安全：减少对外暴露IP个数，增强整个服务集群的安全性。
2、节约成本：复用SLB可以最大限度的利用到单个SLB的带宽，因为SLB的费用主要依赖实例个数和对外流量。

云助你轻松高可用

高可用这个话题如果从广义上说，从代码编写、软件设计、部署架构都会或多或少的影响到服务的高可用，我们这一小节主要是讲部署结构。传统意义上的高可用，体现在部署结构上主要有：同城容灾、异地多活、两地三中心等常见的架构。而异地多活和两地三中心牵涉到更多的是需要自身业务架构师调整架构设计，其中很难处理的如数据同步与服务切换，就与业务有着莫大的干系，这些都需要业务团队针对自身的架构特点有专门的工具来做支撑才能完美支持。不过同城容灾在云上是很好做到的，具体来说，我们可以从以下三个方面讨论。
1、流量高可用：不过既然是集群，就需要保持高可用的能力，我们推荐您在开SLB时选择 “多可用区” 的模式让其具备此的能力。
2、存储高可用：存储节点以阿里云的RDS为例，本身就自带了主备、集群等高可用的模式，如果选择主备模式，默认可以做到跨可用区的同城容灾模式。而且，云上提供的几乎所有的数据服务，都会带备份的功能。
3、计算高可用：如果存储和计算分离之后，计算节点的高可用方式，可以直接根据可用区均匀分布；虽然可用区之间物理上有一定隔离，但是不影响访问速度。

监控与日志

集群规模在某个数量以内的时候，我们查看监控与日志的成本都是可以接受的，当我们的规模超过某个数量（比如：3）台以上，甚至是一个微服务的大集群后，应用维度的日志查看、分析聚合甚至诊断、以及监控报警会瞬间变得迫在眉睫。业内针对这些领域，都有对应的开源的方案，如：日志聚合的ELK，监控报警的Zabbix、诊断领域有各种类型的APM产品。
阿里云上对应的领域也有对应的开源产品的商业化解决方案，如日志服务SLS、APM产品ARMS 、云监控等等。我们推荐使用这些成熟的有人兜底的方案，免去自己运维与搭建的烦恼。

结语

云产品Web应用托管服务（Web+） 的产品设计，正是默认给我们的客户提供了上述十点的最佳实践，全力相助您在上云之路上走的更加的顺畅，产品永久免费，目前正在公测阶段，欢迎体验。

本文作者：中间件小哥

原文链接

本文为云栖社区原创内容，未经允许不得转载。