云原生王四条的缘起是：2021年11月30日在云计算微信群里讨论时，我提出如下观点
基本上这四样做完，业务大致就接近一个云原生的最佳实践状态了:
1. 用对象存储静态文件
2. 用role不能用ak sk
3. 尽量用托管服务
4. 数据不要存在服务器上
群友的观点是这个“刚刚入门”，后续多次提了几次，在此细化一下，进行分条阐述，并且结合一下12-Factor的理念丰富一下细节。
- https://aws.amazon.com/cn/s3/
- 对象存储是相对于块存储，文件存储而言的：
- 对象存储需要一个简单的 HTTP 应用编程接口（API），以供大多数客户端（各种语言）使用。对象存储经济高效：您只需为已用的内容付费。它可以轻松扩展，因而是公共云存储的理想之选。它是一个非常适用于静态数据的存储系统，其灵活性和扁平性意味着它可以通过扩展来存储极大量的数据。对象具有足够的信息供应用快速查找数据，并且擅长存储非结构化数据。
- 当然，它也存在缺点。无法修改对象——您必须一次性完整地写入对象。对象存储也不能很好地与传统数据库搭配使用，因为编写对象是一个缓慢的过程，编写应用以使用对象存储 API 并不像使用文件存储那么简单。
- 参考连接： 文件存储、块存储还是对象存储？
- aws的S3是典型的对象存储服务。国内阿里云叫OSS,腾讯云是COS,华为云是OBS。
- 我们一般认为：内容不需要动态生成的文件是静态文件，此处我们将范围扩大到以文件形式存在的均属于。
- 一次写入，多次读取的文件是比较标准的静态文件
- 也有更新比较频繁的静态文件，至少应该要以文件的形式存在
- 成本优化上：按量使用付费，不需要提前预制大量长期浪费的空闲空间，并且有丰富的存储形式。单价也低于块存储
- 容错能力上：一般都是三副本，可以做版本管理，优于块存储
- 性能上：是公有云的全托管服务，单用户请求可能逊于块存储设备，但是在多用户特别是海量场景下性能有保证。
- 安全性：是公有云的全托管服务，有丰富的安全策略可以配置，只需要在使用注意选择和配置，日常维护由公有云保护。
- 对外公开的文件无需自己维护服务，预签名URL可以方便安全的给用户授权在限定时间内上传或者下载某个特定文件
- 基于公有云的服务，可以方便的对数据进行加密和解密
- 服务限制：扩展性极好。因为空间接近无限制，研发人员无需担心空间不足情况，不需要猜测容量需求。
- 开发优势：因为是基于api的公开服务，所以方便多个服务共享使用，是一个很好的解耦渠道（有助于实现AWS最佳实践4：松耦合组件），并且可以给无状态服务做持久化存储。
- 鼓励研发使用对象存储
- 积极教导研发使用awscli s3
- 积极配合研发设置EC2 Role方便操作s3
- 教导研发使用s3的sdk
- 控制所有有空间限制的服务的空间规模，比如块存储EBS
- EC2不提供大于100G的EBS
- k8s里的pod不提供大于8G的EBS
- 超标请求需要审核
- 块存储的审核可以通过如下方式把控：
- 运维完全把控资源创建：运维来把控标准
- IaC创建资源：审核代码
- 研发自主创建软控制：设定config监控
- 研发自主创建强控制：IAM Policy里设置Condition，用NumericLessThan来控制可以创建的EBS大小
-
- 将静态资产存储在对象存储中
-
- 通过CDN 提供频繁访问的资产
-
- 将非关系数据存储在托管的NoSQL数据库中
-
- 将关系数据存储在托管的SQL数据库中
- https://aws.amazon.com/cn/iam/features/manage-roles/
- 此处的角色，不等同于RBAC模型里的角色，特指公有云服务提供的IAM 服务里的角色，阿里云对应是RAM的角色，腾讯云对应的是CAM的角色，华为云对应的是IAM的委托
- 可通过 IAM 角色为通常没有权限访问贵组织的 AWS 资源的用户或产品授予访问权限。注意：此条主要是强调给产品赋予访问权限，针对的是程序使用的场景。
- 角色切换：良好设计的IAM 产品不仅支持用户的角色切换，也支持其他角色进行角色切换，还支持跨账户的用户和角色进行角色切换，可以非常灵活的授权
- IAM 角色是一种临时安全凭证
- https://docs.aws.amazon.com/zh_cn/IAM/latest/UserGuide/id_credentials_access-keys.html
- 访问密钥 Access Key
- 秘密访问密钥 Secret key
- ak sk 分为永久和临时，临时ak sk 还包含token和失效时间，一般也被称之为STS(Security Token Service)，反对使用的是永久ak sk。
- 永久ak sk相当于是程序使用的用户名和密码，跟人用密码的区别是你很难定位哪些代码在使用ak sk，所以轮换成本极高。
- 安全性
- 防止因为访问密钥丢失造成的安全事故。比如凭证被硬编码到代码，脚本或者文档后被泄露；或者被攻入之后，黑客拿到服务器上存储的访问密钥
- 因为大多数使用ak sk的公有云业务是没有网络边界的，所以一旦丢失，对于业务的威胁是非常严重的，攻击者可以在全球任何位置发起攻击。
- 管理方便
- 避免无法定位访问密钥的位置，从而无法轮换密钥
- 如上面所说，如果发现密钥丢失，是可以进行密钥轮换进行补救的。但是能发生密钥丢失的客户，大致也是管理不好密钥的使用情况，因此轮换密钥可能会导致部分未知业务停摆。
- 开发优势：可以良好的实践 12-factors的基准代码要求：一份基准代码，多份部署，配置要求：在环境中存储配置和开发环境与线上环境等价要求：尽可能的保持开发，预发布，线上环境相同,因为IAM角色是依赖环境的，根据代码部署的环境不同，代码可以获取到不同的权限
- 把控IAM 分配权限
- 普通用户剥夺创建ak sk的权限
- 审核所有ak sk的需求。
- 只批准跨云的需求
- 不要把ak sk直接提供给研发团队以防研发硬编码到代码里
- 而是提供接口（比如kms之类的服务）或者在环境变量里提供
- 托管服务：服务由公有云完全托管管理，客户不关心具体的服务器细节，只通过接口来使用服务，通过公有云的控制台、api、sdk来管理服务，扩展、容错能力和可用性通常内置在服务中
- 非托管服务：服务由客户自建在自我管理的云服务器上，扩展、容错能力和可用由您管理
- 成本优化
- 虽然部分有机型配置的托管服务看起来要服务器贵一些，但是考虑到你需要雇佣相关经验的人员，这个成本是弹性而且划算的。
- 良好设计的托管服务可以在稳定性有保障的前提下方便的扩容缩容，也非常有利于成本的优化
- 容错能力： 托管服务一般具有良好的可靠性，或者比较容易通过良好的设计来实现可靠性
- 性能： 托管服务由公有云专业团队维护，性能一般不会低于自建服务
- 安全性：增强的安全性与合规性
- 在更高的层次做权限控制和数据保护，例如托管的数据库可以通过快照来避免有数据库权限的人删库；更方便做审计
- 托管的服务程序升级和安全性由公有云专业团队保障
- 开发优势：操作灵活，部署快速，服务可靠
- 可以快速尝试所有提供托管服务的产品，而无需担心是否有维护能力
- 有公有云专业团队来提供使用过程中的服务
- 可以良好的实践 12-factors的后端服务要求：把后端服务当作附加资源
- 符合AWS最佳实践5：设计服务而不设计服务器
- 托管解决方案和无服务器架构可以让您的环境实现更高的可靠性和效率
- 对研发主要是鼓励为主,鼓励研发选用托管服务
- 给研发一定的托管服务权限
- 给研发提case的权限以应对托管服务的问题
- 让TAM服务研发
- 运维管住自己的手
- 不自建各种开源服务
- 拒绝任何维护非业务代码服务的要求
- 可以购买商业saas来替代公有云没有的托管服务
- 除代码生成物之外的所有数据，包括
- 日志，等应该存储在S3或者日志服务里的静态文件
- 配置文件，证书，等应该通过外部服务集中管理的配置
- 密钥，等应该通过环境变量配置获取的变量
- 业务数据，等应该存在托管数据库或者s3里的存储数据
- 中间数据，等应该存在消息队列里的应用程序之间的通信
- 不在代码库管理的脚本,crontab等配置
- 一般指具备有限存储功能的计算服务，包括
- 虚拟机：EC2
- 容器：Pod
- 成本优化
- 这是使用竞价实例的前提
- 可以有效减少块存储卷的使用量，对象存储成本远低于块存储
- 容错能力：
- 这是使用ASG弹性伸缩组的前提
- 因为数据不存储在服务器上，所以故障机器的移除不会造成数据丢失
- 安全性：
- 数据不存储在服务器上，可以更好的追溯和监管，可以选用专业的外部服务而且追溯更容易
- 数据存储在服务器上，其访问情况需要安装相应组件来监控，成本较高。
- 开发优势：
- 可以集中分析日志，无需登录每台机器
- 可以更好的实践云原生技术，因为这是使用容器服务的前提
- 配置基于环境生成，部署应用时无需将配置硬编码到代码库，更简单
- 可以良好的实践12factor的进程要求：以一个或多个无状态进程运行应用，基准代码要求：一份基准代码，多份部署，配置要求：在环境中存储配置和开发环境与线上环境等价要求：尽可能的保持开发，预发布，线上环境相同，日志要求：把日志当作事件流
- 符合AWS最佳实践3：使用一次性资源。将服务器和其他组件视为临时资源。
- 只有服务器上面没有数据之后，服务器才能随意启停，才能作为一次性资源
- 符合AWS最佳实践5：设计服务而不设计服务器
- 托管解决方案和无服务器架构可以让您的环境实现更高的可靠性和效率
- 也是AWS最佳实践4：自动部署环境 的前提
- 自动部署的场景包括检测到不正常的资源并启动替换资源，这个前提就是资源是一次性的
- 日志存S3或者打入到ELK等外部服务中
- 配置文件应该通过外部或者环境获取
- 外部就是类似Parameter Store或者其他配置中心
- 环境就是可以通过ec2启动时的用户数据，或者pod启动时环境变量 来注入具体的配置
- https证书应该用acm和相关服务来解耦，或者参照配置文件获取
- 密钥应该通过外部或者环境获取，类似Parameter Store
- 业务数据应该进入s3或者数据库
- 应用之间的中间数据，应该送往消息队列进行解耦处理
- 所有脚本和配置应该代码库统一管理，部署应该按照cicd管理
- 服务器开机，应用服务自启动。
- 将程序设计成无状态，无共享，可以随时终止