《微服务设计》读书笔记
2024-01-24 08:10:46 0 举报AI智能生成
《微服务设计》读书笔记（下）
作者其他创作
大纲/内容
第7章-测试
测试范围
单元测试
单元测试是我们开发人员的，是面向技术而非面向业务的
通过TDD（Test-Driven Design，测试驱动开发）写的测试
在单元测试中，我们不会启动服务，并且对外部文件和网络连接的使用也很有限。通常情况下你需要大量的单元测试。
服务测试
直接针对服务某一个功能接口的测试
对于包含多个服务的系统，一个服务测试只测试其中一个单独服务的功能
为了达到这种隔离性，我们需要给所有的外部合作者打桩，以便只把服务本身保留在测试范围内
端到端测试：用户界面测试
端到端测试会覆盖整个系统
通常需要打开一个浏览器来操作图形用户界面
测试金字塔
比例：测试case的数量问题
单元测试>服务测试>端到端测试
实现服务测试
关键问题是如何打桩，需要一个打桩服务，最好是已有的工具
微妙的端到端测试
覆盖多个服务的端到端测试的一种标准方式
任意一个服务在任何时候只要发生变化，都会触发端到端测试
脆弱的测试
端到端测试失败有时是因为资源竞争、超时等，有时是功能真的被破坏了
当发现脆弱的测试时，我们应该竭尽全力去解决这个问题，并且是尽快
看看能否用不易出现问题的小范围测试取代脆弱的端到端测试。
谁来写这些测试
开发+测试
测试多长时间
运行缓慢和脆弱性是很大的问题
大量的堆积
保障频繁发布软件的关键是基于这样的一个想法：尽可能频繁地发布小范围的改变
部署后再测试
冒烟测试
使用蓝/绿部署区分部署和上线
金丝雀发布（canary releasing）
金丝雀发布是指通过将部分生产流量引流到新部署的系统，来验证系统是否按预期执行
金丝雀发布与蓝/绿发布的不同之处在于，新旧版本共存的时间更长，而且经常会调整流量
非功能的测试：性能测试
第8章-监控
监控的内容，不管是单体架构，还是微服务架构，就只有那么三种
1. 物理机器资源
2. 业务信息
3. 服务的性能
开源实时监控套装：ELK
Logstash：日志收集
ElasticSearch：分布式检索系统，用于数据的分析
Kibana：数据聚合后得到的指标的页面展示
多个服务的指标跟踪
有一个汇总的概要指标信息，方便快速定位问题
有一个详细指标信息，方便分析具体问题
服务指标
尽可能多的记录服务基本指标
我们永远无法知道什么数据是有用的！所以尽可能多的记录下来
这里要考虑的时序DB存储数据
语义监控
伪造case去请求系统服务，服务的响应结果与期望的结果作比较，从而达到监控的目的
关联标识（traceId）
使用关联标识（traceId）来重建调用链
需要标准化，强制在系统中执行该标准
传递关联标识（traceId）时需要保持一致性，这是使用共享的薄客户端库
开源工具库
Zipkin：twitter
Dapper：Google
级联故障监控
每个服务的实例都应该追踪和显示其下游服务的健康状态
应该将这些信息汇总，以得到一个整合的画面
标准化
通过公共库来标准化日志格式，上报的监控指标，指标名称等等信息
考虑受众
我们为不同的人收集这些数据，帮助他们完成工作
老板想知道的数据，和运维人员想知道的数据，肯定是不一样的
对于查看这些数据的不同类型的人来说，需考虑以下因素
他们现在需要知道什么
他们之后想要什么
他们如何消费数据
第9章-安全
身份验证和授权
身份验证
在安全领域中，身份验证是确认他是谁的过程
授权
通过授权机制，可以把主体映射到他可以进行的操作中
当一个主体通过身份验证后，我们将获得关于他的信息，这些信息可以帮助我们决定其可以进行的操作
对于单一的单块系统来说，应用程序本身会处理身份验证和授权
对于微服务架构，我们的目标是要有一个单一的标识且只需进行一次验证
常用的SSO（Single Sign-On，单点登录）实现
企业级领域常用的两种方式
SAML
OpenID Connect
身份提供者
身份验证
目录服务
授权
服务提供者
真正的服务
用户->服务提供者->身份提供者->目录服务->身份提供者->服务提供者->用户
单点登录网关
集中处理重定向用户的行为，只在网关做单点登录
下游服务如何接受主体信息的问题？？
如果你使用HTTP，可以把这些信息放到HTTP头上
一种虚假的安全感
内网与外网之间由单点登录网关做身份验证
内网之内，服务之间的调用是没有身份验证的
单点登录网关一定要简单，不能太复杂
细粒度的授权
单点登录网关可以提供相当有效的粗粒度的身份验证
例如：用户是否登录
细粒度的授权由每个服务提供者自己决定
单点登录网关获取主体属性，透传给下游服务提供者，服务提供者根据这些信息，做细粒度的授权
服务间的身份验证和授权
在边界内允许一切
内网环境，各个微服务之间的调用都允许
如果一个攻击者入侵了你的网络，攻击者就可以为所欲为
中间人攻击
边界内信任这种形式被大多数组织采用
发展初期，没有那么多精力做内网的身份验证和权限控制
需要意识到它的风险
HTTP（S）基本身份验证
在HTTP协议头上透传用户名和密码，服务端做身份验证
通过HTTPS加密
SSL证书管理问题
若经过代理服务转发，则不能在代理服务上缓存数据
使用这种方法，服务器只知道客户端有用户名和密码。用户名和密码泄露，则毫无办法了。
使用SAML或OpenlD Connect
内部服务也通过单点网关来做身份验证和授权
单点网关压力会很大
客户端证书TLS
服务端要管理TLS证书，比较复杂
当你特别关注所发数据的敏感性，或无法控制发送数据所使用的网络时，才考虑使用这种技术
HTTP之上的HMAC（Hash-based MessageAuthentication Code，基于哈希的消息码）
使用HMAC，请求主体和私有密钥一起被哈希处理，生成的哈希值随请求一起发送。然后，服务器使用请求主体和自己的私钥副本重建哈希值。如果匹配，它便接受请求
比HTTPS简单方便、系统开销小的方案
APl密钥
服务方给客户端分配API密钥做签名，然后在签名值的比较
API密钥重点关注的是对程序来说的易用性。相对于处理SAML握手，基于API密钥的身份验证更简单直接
可以采用网关模型
集中管理API密钥
结合目录服务，获得授权能力
由开发者自行决定使用方式，不受通信协议限制
代理问题
有一种安全漏洞叫作混淆代理人问题
已经登录的用户，查询其他账户的订单信息
用户登录成功了，通过了网关的身份验证
静态数据的安全
使用众所周知的加密算法
一切皆与密钥相关
如何管理密钥
使用单独的安全设备来加密和解密数据
密钥和加解密服务在一起
使用单独的密钥库，当你的服务需要密钥的时候可以访问它
密钥和加解密服务分开
选择你的目标
考虑哪些数据需要加密
按需解密
第一次看到数据的时候就对它加密。只在需要时进行解密，并确保解密后的数据不会存储在任何地方
加密备份
深度防御
防火墙
日志
可以让你事后看看是否有不好的事情发生过
入侵检测（和预防）系统
IDS（Intrusion Detection Systems，入侵检测系统）
IPS（Intrusion Prevention Systems，入侵预防系统）
不同于防火墙主要是对外阻止坏事进来，IDS和IPS是在可信范围内积极寻找可疑行为
网络隔离
创建VPC（Virtual Private Cloud，虚拟私有云）进行网络隔离
操作系统
给操作系统的用户尽量少的权限
定期为你的软件打补丁
黄金法则
不要实现自己的加密算法
外部验证
由外部方实施的类似渗透测试这样的实验，模拟现实世界的意图
上面是一种评价安全效果的方法
第10章-康威定律和系统设计
组织结构和他们创建的系统之间的关系
松耦合组织
典型代表是：分布式开源社区
Amazon和Netflix
“两个比萨团队”
没有一个团队应该大到两个比萨不够吃
紧耦合组织
典型代表是：商业产品公司
服务所有权
意味着拥有服务的团队负责对该服务进行更改、测试、部署、运维这一整套的权限
所有权程度的增加会提高自治和交付速度
避免不同团队共享服务
孤儿服务
第11章-规模化微服务
扩展
垂直扩展
性能更加强劲的单机
水平扩展
拆分负载
负载均衡
硬件负载均衡
软件负载均衡
重新设计
你的设计应该考虑10倍容量的增长，但超过100倍容量时就要重写了
扩展数据库
数据库服务是有状态的：数据持久性
扩展读取
读写分离
最终一致性
扩展写操作
使用分片
实质类似于通过哈希来分库存储
新增一个分片，是个很难的事情，因为数据需要重新哈希分配
Cassandra：开源分布式nosql数据，支持不停机增加分片节点
共享数据库基础设施
一个正在运行的数据库可以承载多个独立的模式，每个微服务一个
单点故障问题
CQRS（Command-Query Responsibility Segregation，命令查询职责分离）模式
系统的一部分负责获取修改状态的请求命令并处理它，而另一部分则负责处理查询
好复杂
缓存
按位置分为
客户端缓存
客户端会存储缓存的结果
极大的减少网络通信次数
缓存如何更新的问题
代理缓存
反向代理、CDN（Content DeliveryNetwork，内容分发网络）
服务器端缓存
Redis、Memcache
HTTP缓存
因为HTTP协议的通用性，有大量开源产品可以直接使用，实现HTTP缓存
为写使用缓存
后写式缓存是在缓冲可能的批处理写操作时，进一步优化性能的很有用的方法
为弹性使用缓存
缓存可以在出现故障时实现弹性
隐藏源服务
当发生缓存雪崩时，源服务如何应对超大流量？
源服务快速失败，并填充缓存，恢复缓存服务
调用方应该有断路器，快速失败
保持简单
自动伸缩
预测型伸缩
根据每天的流量分布，在高峰期增加运行的实例，在低谷期减少运行的实例
响应型伸缩
应对突增流量
应对故障节点
CAP定理
一致性（consistency）、可用性（availability）和分区容忍性（partition tolerance）
AP系统，牺牲一致性
要求降低为：最终一致性
CP系统，牺牲可用性
支持分布式一致性是非常困难的
CA系统，牺牲分区容忍性
在分布式系统的世界里不可能存在CA系统
真实世界更加复杂，一般：AP系统会优于CP系统
服务注册与发现
DNS
Zookeeper
Consul
Eureka
ETCD
文档服务
我们会确保文档总是和最新的微服务API同步，并当大家需要知道服务在哪里时，能够很容易地看到这个文档。
Swagger
Swagger让你描述API，产生一个很友好的Web用户界面，使你可以查看文档并通过Web浏览器与API交互
HAL和HAL浏览器
第12章-总结
微服务的原则
围绕业务概念建模
接受自动化文化
隐藏内部实现细节
让一切都去中心化
至可以让团队自己决定什么时候让那
可独立部署
服务上线发布不受其他服务影响限制
隔离失败
避免级联故障
高度可观察
图形化监控
什么时候你不应该使用微服务
服务架构演化过程：从单体到微服务
为服务找到合适的限界上下文后，才开始服务拆分
当你已经有帮助管理微服务的工具后，才进行微服务改造
0 条评论
下一页
为你推荐
查看更多
