架构师需要什么样的能力
架构师需要什么样的能力？我参考了很多外面一些同学的分享，总结出来其实就是发现问题、分析定义问题、解决问题。
对局部和全局的问题需要有发现的眼光，更应该有发现未发生问题的能力，哪些是需要治标，哪些需要治本，这个是发现问题的基本判断力。现在系统可能没什么大问题，但你要有发现的眼光，这些问题如果不解决，未来业务可能遇到更严重的问题。
比如看到一个会员，你不能仅仅只看到会员，你要看到会员上面的业务是什么，谁在用会员，这叫全局。同时，会员用的最多的是导购和交易，登录仅仅是会员本身一个很小的业务功能而已。基于会员，我们有导购有交易，把这些东西要串起来看明白，就能完整的认识到会员到底提供了什么，一定要有一个全局视角。
学习也不是说去瞎学，一定要有体系化的。首先跟你工作相关的，要体系化的去学习，从最下到最上体系化的去学习，学习完了以后你会有新的不一样的认识。把你的想法可以向你的团队说出来，向你的主管说出来。
学习也不是说去瞎学，一定要有体系化的。首先跟你工作相关的，要体系化的去学习，从最下到最上体系化的去学习，学习完了以后你会有新的不一样的认识。把你的想法可以向你的团队说出来，向你的主管说出来。
• 资源管理器（Resource Manger，RM）：事务的参与方，如 MySQL 中的一个库，在 PolarDB-X 中这个角色由存储节点（DN）承担
在上面的只读连接优化中，我们通过将仅使用快照读的连接摘出事务之外，来优化 COMMIT_TS 的获取。而如果是完全相反的情况 ——— 所有连接都是写操作或者带锁的当前读操作，那么我们完全不需要进行快照读。因此我们也做了这样一个优化：仅在第一次进行快照读时获取 SNAPSHOT_TS。这个优化针对的是一些对 Serializable 有很强需求的场景：
而到 2018 年，随着 Service Mesh 的加入，CNCF 对云原生的定义发生了改变，而这也逐渐成为被大家认可的官方定义：
Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.
。这些服务是围绕业务功能构建的，可以通过全自动部署机制独立部署，同时服务会使用最小规模的集中管理（例如 Docker）能力，也可以采用不同的编程语言和数据库。
基于 Guava 限流：Guava 是 Google 提供的 Java 扩展类库，其中的限流工具类 RateLimiter 采用的就是令牌桶算法，使用起来非常简单。
基于 Nginx 限流。
