随着应用、团队、业务功能点数量的增加，所需要的开发测试环境数量还会成倍的增长，造成巨大的资源浪费。对于测试环境的计算资源而言，资源利用率要远低于生产环境。有的时候仅仅是一个简单功能点的验证，为了端对端的跑通业务功能，又避免团队之间的相互影响，就会开启一套包括全部微服务应用的新环境。这样的资源浪费，对于很多企业，都是一个多年都未曾得到解决的难题。
容量存在局限性，32位的长度可以使用136年，一般够用。
并发局限性，低于snowflake。
只适用于int64类型的Id分配，int32位Id无法使用。
算法总结
优点：
完全是一个无状态机，无网络调用，高效可靠。
缺点：
依赖机器时钟，如果时钟错误比如时钟不同步、时钟回拨，会产生重复Id。
故障恢复能力越来越高 - 随着系统自愈性的增强，大大简化了应用架构容错的复杂性。
为了更好地理解云原生计算出现的时代背景，我们必须要理解云计算的经济学基础与核心竞争力所在。
不可变基础设施、可观测、自动恢复
基于 K8s 底座，背后代表的是镜像之类的不可变基础设施以及可观测、自动恢复，如果检测到请求失败，会自动切流或重启实例。
支fb最开始是一个单体应用。随着业务不断发展，支fb拆分成了多个服务，衍生出了若干代架构。微服务是服务化后的进一步演进，服务的粒度比服务化更细，具有很好的流量管控机制，中间件和编程模型。
例如，假设有两个人写数字九(9)，但是他们两个人都以不同的方式写数字(一个人写9，其他人写一个nine，底部没有清晰的曲线)。
端口绑定：通过端口绑定提供服务
12-Factor应用完全自我加载，而不依赖于任何网络服务器就可以创建一个面向网络的服务。互联网应用通过端口绑定来提供服务，并监听发送至该端口的请求。比如，在线上环境中，请求统一发送至公共域名，然后路由至绑定了端口的网络进程。
第一代微服务架构中，应用除了需要实现业务逻辑之外，还需要自行解决上下游寻址、通讯，以及容错等问题。随着微服务规模扩大，服务寻址逻辑的处理变得越来越复杂，哪怕是同一编程语言的另一个应用，上述微服务的基础能力都需要重新实现一遍。
可以看到对外的服务提供了一个统一的SDK，然后集成到所有的外部服务里。在服务端，提供的服务可以大概分为API层和执行层。API层有两个集群 Frontend集群会负责控制流的介入，Tunnel集群负责数据。在执行层分为控制集群和计算集群，控制集群会负责资源管控，meta的管理，和权限管理这些功能，计算集群就负责实际的计算和存储。
