推荐《持续演进的Cloud Native云原生架构下微服务最佳实践》
- Martin Fowler 曾说：优秀的技术人员的观点胜过任何度量，尽管它是主观的。
- 未来是不确定的。架构是锤炼出来的，而不仅是设计出来的。
- 企业领导者的果断、坚决。只要方向没错，就要坚持，绝不动摇。
Martin Fowler
架构是持续演进的，并非一蹴而就的。
- 初级阶段应该采用尽可能简单的架构，因为需求、规模都不是十分明确。
- 可以快速迭代的方式，进行架构演进。
- 腾讯的一条重要发展原则：小步快跑。
高效管理IT 团队：
- 架构设计；
- 研发流程；
- 团队文化；
架构设计注意点：
- 可用性；
- 可扩展性；
- 性能；
- 一致性（分布式事务）；
分布式消息中间件
流控设计
- 漏桶算法（Leaky Bucket）
控制数据注入网络的速率，平滑网络上的突发流量。
- 令牌桶算法（Tocket Bucket）
令牌桶控制的是一个时间窗口内通过的数据量。
- 基于Guava限流
限流工具类 RateLimiter 采用的就是令牌桶算法。
全链路压测
- 找到核心流程（做全链路压测，需要巨大的成本，因此只需要关注核心流程）。
- 选择隔离防晒（独立的环境；或者和生产环境混合，通过参数进行识别）。
重构
尽量不要让拆分服务和数据结构的改变放在一起做，要尽量把一次大的重构划分为几次比较小的重构。
数据库同步方案
- 利用数据库同步工具，通过读取binlog 实现数据双向同步。
- 在业务应用上，同时双写2个数据库。
- 老系统在写数据库的同时，发送消息到消息中间件，消费消息从消息中间件实现同步。
无论采用以上哪种方式同步数据，都不可避免地会遇到一致性问题。
Z轴扩展-分片（Sharding）
采用分片会导致架构的复杂度大幅上升，非必要情况下，应尽量避免。
数据分片的目标：
- 数据量尽可能分布均匀；
- 访问量尽可能分布均匀；
- 一次访问尽可能落到一个分片；
数据分片对原有的架构破坏性很大，需要考虑的地方很多，因此分片的算法至关重要。以下是几种常用的分片算法：
（1）区间法（Range-Based）
（2）轮流法（Round-Robin），如对关键字求余以实现均匀分布。
（3）一致性哈希法（Consistent Hash）
分片后的关联查询问题
（1）建立多维度数据库
相当于为了进行关联查询，多冗余了一份数据。
更新时，通过消息中间件，异步更新到综合数据库内。
查询时，直接从综合数据库查询。综合数据库，可以为 MongoDB。
（2）建立外部搜索引擎
全文检索目前有很多开源方案，如 Apache Solr和 Elasticsearch等等。
（3）分布式缓存
通过分布式缓存，存储结果性数据。
性能（Performance）
（1）通过消息中间件提升写性能
MySQL 5.7 单表8个字段，数据量为 500万，写的吞吐量一般在 1000 TPS 左右。
而Kafka 0.9 三节点集群的吞吐量，能达到 10万 TPS，两者的差距大概是两个数量级。
（2）通过缓存提升读性能
Redis、Memcached 性能非常高，响应时间我毫秒级，单节点吞吐量约为 10万 QPS。
同等条件下，与数据库 几千QPS相比，是一个非常大的提升。
数据库优化
通过将状态外置到缓存、数据库中，来降低业务服务的伸缩复杂度，数据库通常成为各个系统中，最难以扩展的点。
（1）索引（提升读性能，影响写性能，适合读多写少的场景）；
（2）通过慢查询日志分析瓶颈点；
（3）通过提升硬件能力优化数据库的响应（如SSD 硬盘）；
（4）架构设计上，转移复杂度，或者从业务角度优化。
如何实现最终一致性？
閱讀更多 軟件架構 的文章
