微服务和大数据相关的一些笔记

微服务

- 多个服务间调用时，要注意网络失败。可以考虑成熟框架来制定网络重试的策略，并优雅处理失败

- 单一的 请求-应答 模型稳定是稳定了，就是效率不高。考虑批量处理或者流式处理。

- API 网关可以缓存一些信息，不要让用户每次请求都带一堆验证信息。尽量减少消息大小。

- Https的加解密往往是一个性能损耗点。

- 移动客户端发起一次网络连接代价非常大（7-8秒），API网关设计时应考虑到这点，尽量减少用户在多个不同服务之间不断连接。

- IAAS (Infrastructure as a service), PAAS (Platform as a service), SAAS (Software as a service)，每层都可以选择使用成熟的技术，只关注自己的服务所需要实现的功能即可

- 设计良好，基于Ngix网关可以处理20-30w的并发

大数据

- Yarn: 当机也能恢复

- 当机器多到一定的程度的时候，就可能出现硬件错误。设计系统时必须考虑硬件错误存在的可能性。

- 应将服务器节点视为时好时坏

- 如果某个节点出现了问题，应该立即将其从集群中踢掉。而如果节点在后面某段时间恢复过来了，必须遵循一定的规则才能回到集群。

- Raft 协议，可以用于确保数据的一致性

- 集群中通过某种算法，选择一个领导者。所有的请求都交给领导者

- 通过数据操作序列的位置，来确保数据的一致性。如果收到如下序号的数据操作请求：

  1, 2, 5

  则在完成1, 2数据操作后，不能执行数据操作5，而必须等待收到数据操作3, 4，再顺序执行3, 4, 5

- 随着用户数量的增加，数据IO很容易成为瓶颈。

- 选择数据库时，一定要考虑数据库的读写速度。建议进行测试。如DynamoDB的写入速度可以和MySQL进行比较

- 根据用户id决定用户数据存储位置的一些常见办法：

   计算 id的Hash值，在n个存储位置中选择最接近该Hash值的存储位置

   直接将存储位置编号存储在用户id中（注意扩展性问题）

- 数据的迁移问题：如果要在保证7*24的无间断服务下支持数据迁移，则服务层应该支持数据层的redirect请求，以便当服务层访问到一个已经迁移了的数据库时，可以重定向到迁移后的数据库上去。

负载均衡

- 分布式系统的稳定性非常重要，一定要采用成熟框架，不要试图去重复发明车轮。

- 100台机器以内，可能用脚本来管理也行。再多，不用框架就要出事情了

- 某些服务，如新闻类服务，瞬发性高，客户对延迟的容忍低。则这种服务的优先级应该较高。而另外一些服务，如备份，后台搜索等，必须要注意为高优先级服务让路。

- 如果一个分布式算法对数据传递的要求较高，例如深度学习，往往直接用单机加CPU效率更高。不做深思熟虑，简单地试图通过增加节点来想要提高算法的运行速度，往往导致巨大的网络传输损耗（100台机器的运算，40%的时间消耗在数据传输上）。

持续发布

- 要实现7*24小时无间断服务，必须支持滚动发布。

- 支持滚动发布后，发布策略可以是蓝绿或者灰度发布

- Jekens 做CI

- 可以考虑使用 Hadoops 来做测试

微服务