【IaaS开发-学习笔记】

职位需求

主要从事IaaS开发，网络、服务器、虚拟化、中间件、数据库的建设与管理，SAN、存储管理等工作。

云计算服务IaaS、PaaS、SaaS

IaaS、PaaS、SaaS概念

IaaS：基础设施即服务，Infrastructure-as-a-service，是第一层
PaaS：平台即服务，Platform-as-a-service是第二层，有些情况也叫做中间件
SaaS：软件即服务，Software-as-a-service第三层

IaaS基础设施即服务

IaaS（基础设施即服务）：IaaS在虚拟化环境中通过互联网上的公共连接向客户提供计算资源。这些资源包括存储、带宽、虚拟服务器、负载平衡器、网络连接和 IP 地址。它按即用即付的方式按需提供必要的计算、存储和网络资源。

位于最底层，是基础架构即服务，IaaS 通过虚拟化技术，将计算平台同存储和网络资源打包，通过 API 接口的形式提供给用户，用户不用再租用机房，不用自己维护服务器和交换机，只需要购买 IaaS 服务就能够获得这些基础资源。

API全称是：Application Programming Interface，即：应用程序接口。开发人员可以使用这些API接口进行编程开发，而又无需访问源码，或理解内部工作机制的细节。
API接口是项目开发过程中必要的组成部分之一，是客户端应用与服务端应用通信和桥梁。

换句话说，假如我的公司使用了 IaaS 服务，那么我就不再自己购买硬件设备，比如服务器，交换机等等，也无需担心停电了服务器无法服务，网络故障等等问题，IaaS 服务就是提供了基础设施服务，随便在哪家购买虚拟机，但还是需要自己装服务器软件，部署网站。

IaaS就相当于我开麻辣烫店，先买了门面房（基础设施），但是麻辣烫的工具和食材（软件）和店长得我自己来

供应商和工具示例：

aws、gcp、蔚蓝、IBM softlayer 、数字海洋

PaaS平台即服务

PaaS（平台即服务） ：PaaS使开发人员能够在基于云的平台上构建应用程序和服务。PaaS产品可能几乎不需要客户端托管专业知识，并在简单的框架中包含预配置功能。paas供应商会定期更新其服务，提供升级和新功能，并从一开始就通过部署为开发人员提供支持。PaaS以按次付费的方式提供所需资源。

PaaS 在基础设施之上还提供了业务软件的运行环境，如果我的公司采用了PaaS服务，那就不需要再购买服务器，也不需要自己装服务器软件，开发者只用关注自己的业务逻辑，不需要关注底层。

PaaS就相当于我开麻辣烫店，买了门面房（基础设施），买了麻辣烫的工具和食材（软件），但是店长得我自己来

供应商和工具示例：

Heroku、谷歌应用程序引擎、AWS弹性豆茎

SaaS软件即服务

SaaS 是软件开发、管理、部署都交给第三方，不需要关心技术问题，可以拿来即用。普通用户接触到的互联网服务，几乎都是 SaaS。
SaaS就相当于我找人帮我开麻辣烫店，我什么都不用管

示例

谷歌和facebook

IasS开发

IaaS不是提供给一般企业使用，应该是运营商或者大型企业或园区使用，例如某某创新园区购买大批服务器，用于售卖给入住园区的企业，企业不需要购买，只需要租用园区的这些服务器即可。园区既能赚钱，企业也能方便，何乐不为呢。所以IaaS的开发必然会配套消费门户，与运营门户，消费门户方便小企业来买和管理服务（可以分得更细），运营门户方便园区管理他的大量服务器。

在云时代，绝大部分的公有或者私有IaaS云提供商都支持API。程序员可以非常灵活的调用这些API，使用标准的基础设施单元构建自己应用的基础设施架构。

主流的公有IaaS云服务商在提供基础设施云服务的同时，还会提供如数据库服务，监控服务，队列服务，通知服务等一系列常见组件。这些服务同样即插即用，按需付费。

传统开发模式

在传统的开发模式中，开发的整个过程是按部就班就行
但是这种模式存在很大的弊端：

• 工作的不协调：开发人员在开发阶段，测试和运维人员其实是处于等待的状态。等到测试阶段，开发人员等待测试反馈bug，也会处于等待状态
• 线上bug的隐患：项目准备交付时，突然出现了bug，所有人员需要加班、等待问题的处理

瀑布式

瀑布是一种将软件开发和交付的各个阶段（例如，分析、设计、开发、测试）分开的方法，并以线性的方式执行每个阶段。因此，在项目进展顺利之前，可能不会开发代码，如果前几个阶段出现延误，则测试和质量保证的重要阶段可能会缩短或完全省略。如果在测试或质量保证中发现问题，则必须对软件进行重新编码或在开发过程中进一步回溯。
需求→设计→开发→测试→部署

敏捷

升级：非线性敏捷方法，使每个开发阶段独立，并在开发周期的早期和整个过程中纳入持续测试。

优点：允许开发人员根据他们收到的持续反馈在交付到生产之前立即进行更改，从而提高了效率并降低了风险。
缺点：虽然开发使用敏捷性来降低风险和提高效率，但部署仍然停留在线性瀑布结构中，这会减慢交付速度并将测试留到流程的最后——这个流程错误地分割了所有权。这在交付周期中造成了巨大的瓶颈，因为如果在部署接近尾声时发现问题，开发人员需要从头开始。

Devops

DevOps是Development和Operations两个词的结合，将开发和运维结合起来的模式，使得构建、测试、发布软件能够更加地快捷、频繁和可靠。

微服务

微服务（英语：Microservices）是一种软件架构风格，它是以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础，利用模块化的方式组合出复杂的大型应用程序，各功能区块使用与语言无关的**API集相互通信**。

拆分解耦是最终的出路，将项目拆成一个个小的服务单独部署，以电商项目为例如图，将整个项目拆分为用户服务，商品服务，订单服务，积分服务…每个服务单独部署，之间通过互相调用的方式来交互，而且可以将一些基础服务例如上传图片，发送短信等很多服务都需要的基础东西，抽象到一个单独的服务，也就是前些年鼓吹的很厉害的‘中台服务’。拆分部署催生出DEVOPS 再看看这种架构下的开发模式

DEVOPS，运维需要做的上线工作，主要就是将代码部署到对应的机器里面。远程部署一些机器，专门用来管理代码，进行上线工作，由运维事先把上线的规则都给定义好了，开发只要按照他的规则都访问这台服务器进行各自的代码合成和发布，自己上线呢，能用代码自动完成的事情就绝不要手动解决，这是每个开发人员都在想的东西。运维需要做的事情，慢慢的都沉淀到了各个平台上面，例如监控，有专门的监控组件和可视化，基础服务例如服务器，CDN，负载均衡等基础服务可以外包到云服务厂商，日志也有专门的日志工具，链路追踪也有专门的组件和可视化，还有网关等，渐渐的，只要这些都配置好了，开发也可以做运维的部分工作，毕竟开发才是最了解代码的人，哪里出了问题看看监控日志，可以最快速度定位到问题，于是DEVOPS开发模式诞生了，开发也是运维。

devops深度理解

DevOps = 人 + 流程 + 平台

devops实现相关工具

开发前后中涉及到的所有人，流程前期是产品出原型，UI出设计，然后前后端代码开发，QA测试，最终部署上线

devops平台搭建工具

项目管理（PM）：jira。运营可以上去提问题，可以看到各个问题的完整的工作流，待解决未解决等；
代码管理：gitlab。jenkins或者K8S都可以集成gitlab，进行代码管理，上线，回滚等；
持续集成CI（Continuous Integration）：gitlab ci。开发人员提交了新代码之后，立刻进行构建、（单元）测试。根据测试结果，我们可以确定新代码和原有代码能否正确地集成在一起。
持续交付CD（Continuous Delivery）：gitlab cd。完成单元测试后，可以把代码部署到连接数据库的 Staging 环境中更多的测试。如果代码没有问题，可以继续手动部署到生产环境中。
镜像仓库：VMware Harbor，私服nexus。
容器：Docker。
编排：K8S。
服务治理：Consul。
脚本语言：Python。
日志管理：Cat+Sentry，还有种常用的是ELK。
系统监控：Prometheus。
负载均衡：Nginx。
网关：Kong，zuul。
链路追踪：Zipkin。
产品和UI图：蓝湖。
公司内部文档：Confluence。
报警：推送到工作群。

本学习笔记参考了以下大佬的资料，链接如下，深表感谢

https://blog.csdn.net/m0_53321320/article/details/125664258
https://blog.csdn.net/yyyyyyyi/article/details/84505838
https://www.cnblogs.com/yaopengfei/p/15773719.html
https://www.zhihu.com/question/58702398/answer/2583300380
https://javaguide.cn/cs
https://www.cnblogs.com/lkztrovo-lsh/p/14998603.html
https://www.cnblogs.com/lkztrovo-lsh/p/14998603.html
https://blog.csdn.net/qzcsu/article/details/72861891
⼩林coding