关于云原生:极客大学云原生训练营hjjr

2次阅读

共计 2597 个字符，预计需要花费 7 分钟才能阅读完成。

拆分扩容后存在的问题
随着业务的增长，零碎变得越来越宏大, 根据零碎功能拆分红独立而又互通的我的项目, 比如交易零碎、财务零碎、生产流程零碎、物流零碎、网站零碎等等, 然而分布式结构会存在很多问题。对于这些问题每一个都值得深入探讨, 这儿简略的提一下, 前面再开篇幅。

数据共享问题
所有的服务之间数据如何共享同步, 这是一个需要考虑的问题, 微服务架构中, 数据不可能只有一份, 没法避免机器损坏等原因造成的数据丢失, 多份数据之间如何同步? 目前可供参考的解决思路是建立数据中心、搭建数据库集群。

接口调用问题
不同的服务器之间进行调用遵循近程调用协定 RPC

JAVA RMI：Java 近程方法调用，即 Java RMI（Java Remote Method Invocation）是 Java 编程语言里，一种用于实现近程过程调用的应用程序编程接口。它使客户机上运行的程序可能调用近程服务器上的对象。

dubbo: 提供了面向接口代理的高性能 RPC 调用

持久化数据雪崩问题
数据库分库分表, 参考:MySQL 调优之分区表。
资源隔离, 参考: 亿级流量架构之资源隔离思路与方法。
缓存设定数据持久化策略:Redis 持久化之 RDB 和 AOF。
高并提问题
缓存: 诸如缓存击穿、穿透、雪崩等, 参考 Redis 击穿、穿透、雪崩产生原因以及解决思路。

数据闭环: 为了便于理解, 举个例子, 对于淘宝而言, 有网页版、IOS 版、安卓版、还有什么一淘等等, 诚然客户端不一样, 然而展示的商品信息是雷同的, 也就是一件商品, 无论是哪个端用的数据是一样的, 需要一套打算来解决并发下根据雷同数据在不同端进行不同展示的问题, 这就叫数据闭环。

数据一致性问题
这是一个难点, 粗心就是多个服务器之间数据如何保障一致性, 同样的商品在不同客户端服务端端价格应该是一样的, 通常使用分布式锁。

数据库扩容: 集群
先简略说一下分布式与集群的区别, 这两个词儿常常一起出现, 然而意义却有所不同, 分布式会缩短单个工作的执行工夫来晋升工作效率，而集群强调的是提高单位工夫内执行操作数的减少来提高效率。更简略的来说，分布式是将步骤分到每台电脑上，不考虑依赖关系，集群打算是指几个工作同时在处理。

繁多数据库存储难以满足业务需要时, 采取集群的形式, 将数据存储在不同的服务器, 这可能是主主或者主从, 主从中主负责写, 从负责读, 将与数据库无关的压力进行合成到多台机器上。

分布式 ID
在简单分布式零碎中，经常需要对大量的数据和消息进行唯一标识。很容易想到的是利用自增, 然而自增有很多问题，例如 ID 有太强的法则, 可能会被恶意查问收集, 面对数据日渐增长，对数据分库分表后需要有一个唯一 ID 来标识一条数据或消息，这样数据库的自增 ID 显然不能满足需要；特地一点的如商品、订单、用户也都需要有唯一 ID 做标识。此时一个能够生成全局唯一 ID 的零碎是十分必要的。概括下来，那业务系统对 ID 号的申请有哪些呢？

分布式 ID 申请
面对分布式 ID, 需要满足上面的申请:

全局唯一性：不能出现重复的 ID 号，既然是唯一标识，这是最基本的申请。
趋势递增：在 MySQL InnoDB 引擎中使用的是会集索引，因为少数 RDBMS 使用 B -tree 的数据结构来存储索引数据，在主键的抉择下面咱们应该尽量使用有序的主键保障写入性能。
枯燥递增：保障下一个 ID 肯定大于上一个 ID，例如事务版本号、IM 增量消息、排序等非凡需要。
信息安全：如果 ID 是间断的，恶意用户的扒取工作就非常容易做了，间接按照次序下载指定 URL 即可；如果是订单号就更危险了，竞对可能间接知道咱们一天的单量。所以在一些利用场景下，会需要 ID 无规则、不规则。
上述 123 对应三类不同的场景，然而 3 和 4 的需要是互斥的，也就是无奈使用同一个打算满足。除了对 ID 号码自身的申请，业务还对 ID 号生成零碎的可用性申请极高，设想一下，如果 ID 生成零碎瘫痪，整个与数据无关的动作都无奈执行，会带来一场劫难。由此总结下一个 ID 生成零碎起码应该做到如下几点：

平均提早和 TP999 提早都要尽可能低；
可用性 5 个 9(这是美团的申请, 有些企业例如阿里申请 6 个 9)；
高 QPS。
分布式 ID 生成策略
目前业界罕用的 ID 生成策略有很多, 例如 UUID、雪花生成算法、Redis、Zookeeper 等, 这儿只简略讲讲 UUID 以及 Snowflake，前面要开篇详谈。

UUID 生成算法
UUID(Universally Unique Identifier) 的标准型式蕴含 32 个 16 进制数字，以连字号分为五段，形式为 8 -4-4-4-12 的 36 个字符，示例：550e8400-e29b-41d4-a716-446655440000，到目前为止业界一共有 5 种形式生成 UUID，详情见 IETF 公布的 UUID 规范 A Universally Unique IDentifier (UUID) URN Namespace。

长处：

性能非常高：本地生成，没有网络消耗。
缺点：

不易于存储：UUID 太长，16 字节 128 位，通常以 36 长度的字符串示意，很多场景不实用。
信息不安全：基于 MAC 地址生成 UUID 的算法可能会造成 MAC 地址泄露，这个漏洞曾被用于寻找梅丽莎病毒的制造者地位。
ID 作为主键时在特定的环境会存在一些问题，比如做 DB 主键的场景下，UUID 就非常不实用：
① MySQL 官网有明确的倡导主键要尽量越短越好[4]，36 个字符长度的 UUID 不符合申请。

All indexes other than the clustered index are known as secondary indexes. In InnoDB, each record in a secondary index contains the primary key columns for the row, as well as the columns specified for the secondary index. InnoDB uses this primary key value to search for the row in the clustered index.If the primary key is long, the secondary indexes use more space, so it is advantageous to have a short primary key.

② 对 MySQL 索引不利：如果作为数据库主键，在 InnoDB 引擎下，UUID 的无序性可能会引起数据地位频繁变动，重大影响性能。

正文完