122 lines
14 KiB
Markdown
122 lines
14 KiB
Markdown
# 09 | 什么是PaaS？怎样深入理解和评估PaaS？
|
||
|
||
你好，我是何恺铎。
|
||
|
||
欢迎你来到我们《深入浅出云计算》课程的第9讲，这也是我们PaaS篇的第1讲。让我们继续精彩的云计算之旅。
|
||
|
||
PaaS，对你来说也许不是一个陌生的词汇，你可能早已从业界大咖或身边同事的高谈阔论中屡次听到这个字眼。不过，很多人对于PaaS服务的评价，可是既有“真香快来”的赞赏，也不乏“大坑勿入”的批评，面对如此两极分化的评价，你估计也有点拿不定主意。这些如雷贯耳的PaaS服务们，究竟靠不靠谱、好不好用呢？
|
||
|
||
作为极客时间的一名“极客”，咱们人云亦云可不行，必须要建立起对PaaS的系统认知。从今天开始，我们就来好好地研究一下PaaS。
|
||
|
||
让我们先从它的定义说起。
|
||
|
||
## 什么是PaaS？
|
||
|
||
在IaaS篇中，我们主要是侧重于基础设施类的云服务，尤其是虚拟机、云磁盘、云网络等服务。它们的特点是，和传统IT基础设施往往有一个对应关系，所以被称为基础设施即服务（Infrastructure-as-a-Service）。
|
||
|
||
今天我们的主角**PaaS** （Platform-as-a-Service），则是指云计算提供的平台类服务，在这些平台的基础上，用户可以直接开发、运行、管理应用程序，而无需构建和维护底层的基础设施。
|
||
|
||
用更通俗的话来说，**PaaS是在IaaS的基础上又做了许多工作，构建了很多关键抽象和可复用的单元，让我们用户能够在更上层进行应用的构建，把更多精力放在业务逻辑上。**
|
||
|
||
拿房子装修来打个比方的话，IaaS就好像空空如也的毛坯房，我们还需要操心墙面、地板等基础性工作；而PaaS就好比精装修的房子，我们只要搬入自己喜欢的家具（业务逻辑），再适当装饰就可以“拎包入住”，开始美好生活了。
|
||
|
||
小提示：PaaS本身也是基于底层IaaS构建出来的，使用了云上的各种基础设施。只是这个步骤云服务提供商代替我们用户完成了，还进行了一定程度的封装。
|
||
|
||
当然，随着PaaS服务形态种类的增多、边界的不断扩展，除了那些包含语言运行环境、可编程和可扩展的经典PaaS服务之外，还有更多的在云上用来辅助应用构建，或帮助运维的服务，也归入了广义上PaaS的范畴。这也是有道理的，因为它们同样是完整的现代应用程序生态的一部分。
|
||
|
||
## PaaS服务的核心优势是什么？
|
||
|
||
如果你去回顾云计算的历史，可能会惊奇地发现，PaaS并不是在IaaS已经非常丰富和完善之后才出现的，它们甚至可以说是“同龄人”。因为在云计算发展的初期，不同公司选取了不同的发展路线，有的侧重IaaS，有的则先押宝了PaaS路线。
|
||
|
||
拓展：不论是IaaS还是PaaS，想要做好都不容易，需要云厂商很大的投入。如果你对于相关的早期历史有兴趣，可以参考我在InfoQ上发表的文章[《激荡十年：云计算的过去、现在与未来》](https://mp.weixin.qq.com/s/AZV2ejFGjDnJ_488XoUWYA)。
|
||
|
||
从某种角度讲，PaaS其实更符合云的初衷，它代表了一种完全托管的理想主义，也更能代表人们对于研发生产力的极致追求。
|
||
|
||
**所以PaaS服务的优势，就在于生产力，在于效率，尤其是在搭建和运维层面。**比如我们课程后面会讲到大数据类的PaaS服务，你可以很方便地一键启动规模庞大的大数据集群，即刻开始运行分布式计算任务。想一想，如果是由你自己基于虚拟机来进行搭建的话，肯定得花上不少功夫。
|
||
|
||
注：进一步地来说，云上的各种PaaS服务是可以互相配合叠加的。运用得当的话，它们联合起来爆发出来的能力会非常强，效率优势会更加凸显出来。
|
||
|
||
这里我给你举一个例子，来说明一下PaaS服务的优势。
|
||
|
||
**日志服务**是我们应用程序后端不可或缺的一个组件，通常我们会组合使用ELK（Elasticsearch+Logstash+Kibana）技术栈来自行搭建一个日志存储和分析系统。
|
||
|
||
而在云上，你可以轻松地找到PaaS服务来为你代劳。比如阿里云日志服务，就提供了一个端到端的日志收集、查询、分析和可视化的解决方案。在这个过程中，你不需要搭建和维护任何基础设施，只要按照产品提示进行设置就可以了。
|
||
|
||
利用阿里云的日志服务，我大概花了1分钟的时间，就建立了一个日志服务实例，并让它收集某个虚拟机/ data目录下的日志文件。随后，我在目录中放置了一本小说《双城记》，很快这个文本文件就被自动传送到了日志服务，并索引起来。然后我就可以利用PaaS的功能，来进行各种查询分析了。
|
||
|
||
下图为我搜索单词“happiness”的效果示例：
|
||
|
||
|
||
|
||
阿里云日志服务的简单示例
|
||
|
||
## 怎样入手学习研究PaaS？
|
||
|
||
由于软件构造的复杂性，用户对于可复用组件的需求是非常多的。所以经过多年的发展下来，云上的PaaS已经是琳琅满目、种类繁多。我们后面的课程也会陆续地讲解各种不同形式、服务不同目的的PaaS服务。
|
||
|
||
但在那之前，我想告诉你观察和认知PaaS服务的方法。这里有几个重要的维度值得你探寻和了解，让你能在清楚了它本身的业务用途之外，还可以洞察这个服务在产品设计和内部实现方面的一些信息。
|
||
|
||
**第一个维度，就是服务是否带有内生的运行环境。**
|
||
|
||
我个人把它称为“承载性”，即服务有没有运行时或执行环境，来承载我们具体业务逻辑的代码或配置。如果有，那么你需要去熟悉它的运行环境，了解它支持的语法，探寻各种参数设置。比如说，Web服务可能带有Java、.NET等的运行时，数据库服务可能会包含SQL的执行引擎。
|
||
|
||
如果没有内含的运行环境，那就说明这个PaaS属于“开箱即用”的工具类型，也就是直接依靠自身内置功能来向你提供支持或帮助。这时它功能的完善程度，以及和你需求的匹配程度，就比较关键了。
|
||
|
||
**第二个维度，是PaaS服务存在的位置和范围，以及给予你的控制粒度。**
|
||
|
||
这个怎么理解呢？其实就是当你新建一个PaaS服务的实例，你一般会需要告诉系统部署的目标位置在哪里。请你注意，这个目标位置的选项是值得玩味的。比如你要仔细看看，这个服务是只能粗放地允许你指定区域，还是可以细化到可用区，以及是否能够设置为部署在具体某个私有网络之内等等。
|
||
|
||
这个维度的信息，一方面潜在地体现了PaaS服务的规模和可用性。比如云存储类服务一般只能让你选择区域，因为它本身冗余性方面的多可用区架构要求，决定了它无法支持指定更精细的位置。
|
||
|
||
另一方面，这个维度也反映了你对这个服务的掌控程度，你会知道它是否能够和你现有的架构进行深度集成。比如说，你很可能要求数据库PaaS服务必须位于你指定的VPC内，这样查询流量就能走内网通信，避免对公网暴露数据库。
|
||
|
||
**第三个维度，在于服务是否是“有状态”的，也就是指服务是否具有较强的数据属性。**
|
||
|
||
有些PaaS服务本身是无状态的，比如无服务器函数，这意味着它们比较容易扩展和提升规模；有些PaaS服务则会保存状态，或者说建立的初衷就是为了维护各种复杂的状态和数据。这对应着PaaS在计算存储能力输出上的不同角色和分工。
|
||
|
||
**第四个维度，体现为支撑PaaS的虚拟机是否对外暴露，也就是会不会显示在ECS、EC2等虚拟机服务的门户列表中。**
|
||
|
||
这是一个很有趣的视角。因为作为PaaS实现者，云厂商既可以选择开放，也可以不开放。有时针对同一类的服务，不同的云也可能采用不同的做法，这体现了云厂商在规划产品上的不同思路，也和它们各自的实现原理有关。
|
||
|
||
通常来说，暴露虚拟机的PaaS服务，拥有更高的开放程度，和IaaS的结合也更加紧密，甚至能够和其他IaaS服务配合联动。在成本方面，这种形式还可以和预付费的虚拟机兼容，让我们享受折扣。
|
||
|
||
而不暴露虚拟机的PaaS服务呢，往往意味着更好的独立性和封装性，说明它不希望你绕开机制来访问虚拟机，比如大多数的数据库服务。还有一种常见的可能是，这个服务需要专用硬件的配合，并非纯粹依赖虚拟机。
|
||
|
||
好了，有了上面的这些视角，相信你即便是对于一个新的PaaS服务，在快速研究之后，也能迅速地把握好要点并进行归类，同时形成清晰的高层次认识。对于它是否适合在你的架构中担任角色，你也会有一个大致的判断。
|
||
|
||
## 衡量评估PaaS的局限
|
||
|
||
我们都知道，软件工程的领域没有银弹。强大的PaaS也不例外，也有自己的局限。
|
||
|
||
**PaaS的核心理念在于封装，封装既带来了效率的优势，也同时带来了灵活性上的牺牲。**我们需要在内置的设定和选项中开展工作，不能天马行空、随心所欲。PaaS的应变能力也会差一些，比如当它出现一些Bug或者运营事故时，你无法自己动手去解决它，而是需要等待厂商进行修复。
|
||
|
||
这是PaaS诞生以来就伴随着质疑的原因，你的身边可能就有PaaS的反对者。有些以前只做PaaS的公有云公司也不得不向市场妥协，陆续开始了IaaS产品的研发。这和早期云市场的接受程度有关，也和当时PaaS自身的成熟度有关。
|
||
|
||
当然，这里我讲的局限性，不是为了奉劝你远离PaaS，而是让你能更加客观地看待PaaS这个产品形态，更好地评估某项PaaS服务是否适用于你的场景。因为PaaS在带来巨大效率提升的同时，也的确要牺牲一点“自由”。
|
||
|
||
这里，我要给你介绍一些检查PaaS限制的方法，也是考察评估PaaS服务成熟度的重要思路，你需要好好参考和把握。
|
||
|
||
* **功能屏蔽**：和自建服务相比，你需要研究PaaS的封装是否带来了某项功能、部分选项，还有扩展机制的屏蔽或者缺失，以及这些功能对你而言是否重要。
|
||
* **版本选择**：你需要检查PaaS所提供的软件或运行环境的版本是否丰富，最早和最新的版本各是什么，还有版本粒度是否足够细致等等。我就曾经遇到过，因为所需数据库版本在PaaS上不存在，只能选择虚拟机进行部署的情况。
|
||
* **性能极限**：确认PaaS服务所能够提供的性能极值，包括算力和存储的上限。你要和自己的需求量预测结合起来，避免“上车”后骑虎难下。
|
||
* **更新频率**：查看PaaS服务的更新日志，了解云厂商和相应团队在这个PaaS服务上，是否还在继续做投入，是否在跟进一些最新的技术趋势。
|
||
* **成本陷阱**：实际地通过POC实验，对PaaS服务进行试运行，注意要达到一定的量级，然后仔细查看它对应的账单，看看相关支出是否合理，你能否长期承受。
|
||
|
||
注：所以对于PaaS来说，其实设置界面选项越多往往越好，这也不失为一个甄别产品成熟度的简单办法。你不应该担心产品学习曲线陡峭的问题，这些不起眼的选项很可能在某个时刻被派上用场，发挥关键的作用。
|
||
|
||
我还是要再次强调，你应当理性地看待PaaS。它肯定不是无所不能，但也绝非一无是处。更客观地学习了解它，有助于建立你对PaaS的理解和信任，在合适场景下，最大化地发挥它的优势和价值。
|
||
|
||
我个人对于PaaS还是非常看好的，它近年来日新月异的发展，已经极大地提升了竞争力。随着大量用户的不断实践和反馈，这些产品也越来越开放，突破了过去的很多限制。有时即便PaaS相对自建会稍微贵一些，我也会优先选择PaaS，因为它带来的效率提升，和时间人力的节省，远远超出了贵出的那点价格。
|
||
|
||
最后我想再补充一点，当云上官方的PaaS不足以满足你的需求时，还有第三方PaaS是值得考虑的选择，你通常能够在云厂商的各种云应用市场中找到它们。比如说，大数据领域中，炙手可热的Databricks公司，就分别在AWS和Azure云都上架了自家的PaaS服务，比起内置大数据的云服务来说，也毫不逊色。
|
||
|
||
## 课堂总结与思考
|
||
|
||
作为PaaS篇的第一讲，我就先和你讨论到这里了。希望通过今天对PaaS的讲解，能够给你建立起一个对PaaS宏观层面的正确认识。同时，我今天介绍的几个观察评估要点，的确是你研究PaaS时值得参考的良好视角。后面在跟随课程讲到具体的各个PaaS服务的时候，也请你记得时不时地回看这一讲的内容，相互印证。
|
||
|
||
我自己是一个PaaS的乐观主义者。如果把你要构建的应用比作高楼大厦，那么PaaS作为大厦的基石和支柱，它是当之无愧、值得信赖的。在充分客观了解PaaS局限的前提下，你不妨积极大胆地拥抱PaaS吧。
|
||
|
||
**好了，今天我留给你的思考题是：**你目前接触使用最多的PaaS服务是哪个？它给你带来了怎样的效率提升？同时它有没有什么局限让你伤脑筋呢？
|
||
|
||
欢迎你在下方留言。如果你觉得这篇文章有帮助，欢迎你把它分享给你的朋友。我是何恺铎，感谢阅读，我们下期再见。
|
||
|