Reliable Cloud Infrastructure: Design and Process学习笔记

最后更新2022/03/16

忘记更新对应的学习笔记，补上。这一科有9节，加上0章简介

简介

google cloud的好多功能有点相似，这科内容是介绍应该选什么产品，怎么选择，怎么规划，怎么设计等等。首先，你要有个软件产品的设计思想，包括对需求和用户的定义，这个没人能帮你，要你自己解决，google cloud只是个辅助的实现工具，要拿这个工具干什么，你自己决定。

有了这个核心设计思想之后，就要对实现过程进行解构，例如将大目标——10个亿，变成10个1个亿的小目标。。。在现代设计中，基于云架构的系统，最佳的实现方案是采用微服务的模式，换句话说，10个一个亿的小目标并非10个单一一亿目标重复10次，如果这样，和1个10亿目标没什么区别，他们之间的关联太密切了。这10个一个亿的目标是完全独立的10个不同目标，只是恰好他们各是1亿而已，实际上，可能是3亿，5千万，1亿2等等10个各不相同的目标，只是他们之和恰好10亿而已，任何两个小目标之间，最好没有任何联系。当然，作为复杂的软件体系，子目标之间不可避免要互相关联，以上说明的目的只是在于尽力求简，简化到每个目标只依赖于最简单的某个google云服务既可实现。（其实，跟没说一样。。。到底要怎么办，还得以后具体分析）

然后，还要有存储，去恰当地保存以上目标在实现过程中的数据，当然也要包括承载实现目标的一切，代码，参数等等。

请从下面选择出你需要的产品，每个一个图标，有没有搞错？！美式幽默而已。
当然，还要有安全，还要有监控等等。下面就具体介绍设计的详细过程：

1. 定义服务
2. 微服务设计和架构
3. DevOps自动化
4. 选择存储方案
5. 选择云及混合网络架构
6. 在google cloud部署应用
7. 设计可靠的系统
8. 安全
9. 维护和监控

在实操之前，咱们要现有个假设的需求，这个例子里是一个叫做ClickTravel的旅游代理公司，想要建立一个全球规模的电子商务网站为客户服务。主要功能包括：

• 为游客提供查找和下定单服务，包括飞机、酒店、火车、租车
• 根据用户单独需求定价（显然大数据杀熟！！！）
• 强大的信息交流功能，包括评价、发帖、分析等
• 供应商（飞机、火车、酒店）能提供（实时）库存

该系统的用户包括：

• 旁观路人甲游客
• 已下单用户
• 供应商
• 经理

定义服务

定义服务首先要了解需求，也就是我们要干什么。

需求

现要搞清requirements，需求概括起来是5个W，11项：

1. who

• 用户是谁？
• 开发者是谁？
• 运营者是谁？

2. what

• 我们搞的这个玩意儿是干什么的？
• 最主要功能有哪些？

3. why

• 为什么需要这个系统？

4. when

• 什么时候用户要交货？
• 什么时候开发者要完工？（为啥和交货不是一个时间呢？测试？改进？）

5. hoW

• 这玩意工作的如何？
• 有多少用户使用？
• 有多少数据？

user和role

需求可以用user story进行描述。那么什么是用户？在定义用户，user的时候，有一个关键词：角色

• 角色role不是单独的人或者头衔，一个人可能扮演多个角色，一个角色也可能由多人扮演，每个人具有相同的特质
• 角色需要是一种标签，能够描述特定的用户行为：用户要做什么？仅仅“使用”并非一个贴切的定义，每个人都会“使用”“操作”我们要设计的系统
• 角色举例：购物者、账户拥有者、客户（精确点说：逛街的）、管理员、经理

确切来说，用户并非一个物理人，它应该是持有特定行为的系统使用者的分类，这个分类则是为了分析系统而设定，特定行为也不见得是人类动作、操作，例如一个微服务客户端访问另一个微服务提供者，这个微服务客户端的访问行为也具有角色的特点，会根据具体设计而进行归类设计。

user story

在设计时，要对role进行多次发散、合并（除重、归类）的过程，尽力做包含所有动作要求且不交叠重复。同时，使用用户故事（user story）的方式来表达这个需求功能特征：

1. 角色，也就是user
2. 动作，完整操作过程
3. 价值，为什么要这个功能，能实现什么价值

下面是一句话的user story：
账户查询
作为一个账户拥有者（角色），我需要随时可以检查账户余额（动作）以避免我的账户透支（价值）。

可以以这个为模板：
As [ type of user] I want to [ do something ] so that I can [ get some benefit ]
或者：
Given [ some context ] When I [ do something ] Then [ this should happen ]

User story是进行（程序）系统设计的关键，可以用INVEST模型去确定user story：

• Independent: 用户故事（个人觉得用用户动作、用户事件、用户操作更好）需要是独立事件，以避免在规划和调度调整时与其它事件冲突；
• Negotitable：可调整的，可变通的，这是需要完成的动作或事件，但又不是100%严格规定了什么时候做，怎么做，被写到合同中，按精确步骤执行的事情。并且，这是一个用户和开发者之间的妥协和交互，用户说我要！开发者说这样行不？用户说那里要加点。开发者说太难，我在这里给你加点。。。
• Valiable：有价值的，最终必须对用户有用，即使是领导每天不一定看的报表，对领导这种特殊用户，也是有用的，虽然他并不看；
• Estimatable: 可评估的，换句话说，是可实现的，有方法的，如果属于未经证明的猜想，显然不在此列。例如，对程序员说：我需要年底销售额预测！这不是程序完成的，这先要由商业咨询拿到预测公式，有公式，有基础数据来源，这就是可评估的，没有这些，就是找错了人。
• Small：这个特性我喜欢，用户故事必须很小，可以很“容易”快速实现，如果太庞大，太复杂，说明拆分不够细；
• Testable：可测试，不能测试，实现了啥功能，结果对不对，谁都不知道啊！

SLO，SLA，SLI

这是对需求进行评估的一组参数或规则。
上一节说过对user story（及完成结果）要能测试和评估，例如在给定的限定条件下（时间、资金、人员），能达到什么样的结果？

KPI就是对这些结果进行评估的具体指标的统称，其实，KPI就是把远大理想翻译成人话并且有实际数据可以进行比较：
Goal: 增加网店的转化率
KPI：网络销售额与网络流量的比率

既然KPI是人话，那就是可以达到的，它需要具有SMART特征：

• Specific：写得清清楚楚，明明白白，直截了当。不能是：请参考本文第二段第三行之类；
• Measurable：又强调一遍，要可落实的具体数据，不说精确到小数点后六位，至少也要是ABCD，与家长对话中：考得怎样啊？还行，这种是无法蒙混过关的；
• Achievable：不能自不量力，对吧？设定不切实际的目标等于没有目标；
• Relevant：有关联的，不是胡说八道的。我们要超英赶美，这就是Goal，亩产要达到1万斤，这就是KPI之一，而且亩产1万斤，全国粮食产量肯定赶美了，这就是有相关性。如果设定KPI为只生一个好，不能说没有relevant，如果中国人口比美国还少，是不是人均GDP就比美国还多？能赶美了？但这个相关性有点牵强。
  -Time-bound：有时间范围。大部分KPI都是在一定是小范围内有效，而且会随着时间范围急剧变化，没有时效范围限定，KPI往往失去意义。

下面是这几个名词之间的关系：
SLI，service level indicator是与server密切相关的KPI
SLO，service level object是基于SLI所要达到的目标，指标
SLA，service level agreement把SLO固化到纸面协议的合同文本，如果供应商没达到，会有罚金付给用户作为补偿；

由于SLI是KPI中的一种，所以必须是measurable且具有time-bound，而目标结果SLO则需要achievable且relevent

SLO设定的标准：

• SLO不是越高越好，与之相反，SLO是在你客户能容忍的情况下，越低越好。老板给员工发工资，就深谙此道。
• SLO越高，计算资源和操作成本越高
• 应用不要提供太高的SLO，用户基本满足于你日常提供的服务指标，只要你别做得更差

注：前互联网时代或许如此，如今。。。特别是越来越多mission critical的应用被移植到互联网，而且自媒体的信息裂变链式反应能力越来越强大，今后互联网应用估计也会按照任务对重要性进行分类吧？

举例：
SLI: HTTP成功响应延时在200ms之内
SLO：99%的HTTP响应延时<=200ms
SLA: 如果HTTP响应延时大于300ms的百分比超过1%，则用户会收到补偿金

微服务设计和架构

这节介绍如何将单体应用拆分为微服务应用，确定微服务的边界，设计有状态及无状态的服务以优化性能和可靠性，按照12指标进行应用部署，建立松耦合的REST架构，设计一致的、标准的RESTful API服务。

先看什么是微服务

微服务

微服务是一种架构模型，是将一个整体的大单体程序拆分为若干很小的、相互独立的服务模块程序。Google提供了若干引擎去支持运行各种微服务模块程序，包括：App Engine，GKE，Cloud Run，Cloud Function，各自有各自不同的颗粒度和承载特点。

微服务和单体应用各有优缺点，具体不写了。

设计微服务的关键点在界定微服务的边界，也就是做拆分时从什么地方下刀，切分功能的同时，还要考虑如何在操作系统层、数据层已经UI表现层进行纵向整合，同时，如果同一微服务模块为多个体系服务，还要研究如何进行服务隔离。

有状态和无状态

现要区分出有状态和无状态的区别，只要不需要随时间、访问实时变化的数据的服务都属于无状态服务。同时，有状态的服务也往往可以拆分为无状态处理和状态数据保存（处理）两部分，而前者是无状态的。

有状态应用难以扩展（并行），难以升级（需要一致数据导致必须绝对意义的升级中断时间），需要备份（逻辑上数据只有也只能有一份，即使物理层镜像不能保证数据可靠）。

基于以上特点，将业务尽可能由无状态处理完成是设计要点，但由于性能、可靠性、复杂性等等因素，有时又不可避免需要设计有状态服务。下面一些设计要点可以帮助减少有状态服务：

尽力避免在server的内存中保留需要共享的状态信息。因为如果状态信息是需要共享的，而server的内存又显然是非共享的，这就要求同一session访问请求必须始终发送到同一server（只有这个server实例才拥有状态数据），防火墙或者负载均衡设备必须保存session标识（配置为sticky session模式既session affinity），并根据此session标识进行转发，额外负担极大。

解决方案是配置共享的后端存储保存状态信息，可以是firestore或者cloud sql，而如果需要性能，则可以增加memorystore，这些都是google cloud提供的标准服务。

最佳实践是这样的5层结构：<