云原生：运用容器、函数计算和数据构建下一代应用 ([美] 鲍里斯·肖勒（Boris Scholl） etc.)（Z-Library）

【One-Line Pitch】 A practical architecture guide for developers and architects who need to design, build, and operate cloud-native applications using containers, serverless functions, and cloud data services—without being tied to one vendor's cookbook. 【Book Arc】 - **Opening (~0%–11%)**: Frames the shift from traditional servers to cloud-native thinking—distributed-system fallacies, the twelve-factor mindset, and why containers plus orchestration (Kubernetes) become the new baseline. - **Early (~11%–33%)**: Covers the core building blocks: microservices, containers vs. functions (FaaS), service communication, API compatibility, messaging protocols (MQTT/AMQP), pub/sub, and gateways for ingress/egress traffic control. - **Middle (~33%–56%)**: Turns to data: object/file/block storage choices, change data capture, GraphQL data services, CDN caching, data lakes vs. warehouses, and running stateful systems on Kubernetes. - **Late (~56%–78%)**: Moves into DevOps practice—test pyramids, local-to-remote development workflows, slim container images, observability with Prometheus/Grafana, health/readiness probes, and configuration via ConfigMaps. - **Ending (~78%–100%)**: Closes with migration patterns (strangler/anti-corruption layer), security and shared responsibility, scaling stateless services, deployment hygiene, and the real trade-offs of portability across clouds. 【Key Takeaways】 - **Cloud-native design starts with distributed-system realities** (Opening): network unreliability, latency, and partial failure must shape architecture from day one, not be patched later. - **Containers and functions solve different problems** (Early): containers suit long-running, stateful-ish services; FaaS suits event-driven, short-lived work—but FaaS cost and network overhead can surprise you. - **Loose coupling via messaging is a first-class pattern** (Early): pub/sub, MQTT, and AMQP enable event-driven designs; choose based on simplicity vs. feature richness and vendor compatibility. - **Data storage is a design decision, not an afterthought** (Middle): object storage is the default for files; file and block storage cost more; change data streams let you sync search indexes, analytics, and legacy systems. - **Testing follows a pyramid, and testability drives design** (Late): unit tests with mocks, service-level tests, and minimal UI tests; if mocking is hard, refactor the code. - **Small images and small deployments reduce risk** (Late): multi-stage builds and slim base images shrink attack surface and speed up scaling; keep functions single-purpose. - **Observability must be prepared before release** (Late): define health/liveness/readiness endpoints and a small metric set with rollback rules before routing production traffic. - **Portability has a price** (Ending): standards like OpenAPI, SMI, and MongoDB-compatible APIs help, but you may lose vendor-specific features and pay for third-party services separately. 【Reading Tips】 - Deep-read Chapters 2–3 for containers, orchestration, and service communication—these are the conceptual spine. - Skim the data chapter if you already know storage tiers; focus instead on change data capture and GraphQL sections. - Treat the DevOps and observability chapters as a checklist to apply to your own pipeline, not just theory. - The portability chapter is best read last, after you understand the trade-offs of the earlier patterns. 【Coverage Limits】 This guide is based on stratified excerpts covering roughly the first through final chapters; some mid-book details on specific cloud provider services and code examples are not fully represented.