微服务架构设计模式--------第一章笔记

第一章.逃离单体地狱

迈向单体地狱的漫长旅程

1.单体架构的好处

• 应用的开发简单

• 易于对应用程序进行大规模的更改

• 测试相对简单直观

• 部署简单明了

• 横向扩展不费吹灰之力

2.什么是单体地狱

• 项目过度的复杂性会吓退开发者
• 开发速度缓慢
• 从代码提交到实际部署的周期很长，而且容易出问题
• 难以扩展
• 交付可靠的单体应用是一项挑战
• 需要长期依赖某个可能已经过时的技术栈

3.你会在本书中学到什么

读完本书，你会理解和掌握如下知识：

• 微服务架构的基本特点，它的好处和弊端，以及应该在什么情况下使用微服务架构
• 分布式数据管理的架构模式
• 针对微服务架构应用程序的的有效测试策略
• 微服务架构应用程序的部署方式
• 把单体应用重构为微服务架构的策略

你也会掌握如下技术：

• 使用微服务的架构模式来设计应用程序的架构
• 为服务开发业务逻辑
• 使用Saga在进程间维护数据的一致性
• 实现跨服务的数据查询
• 更高效地测试微服务架构应用程序
• 开发生产环境就绪的应用程序，实现安全性、可配置性和可观测性
• 把现有的单体应用重构为服务

拯救之道：微服务架构

1.扩展立方体和服务

X轴扩展：在多个实例之间实现请求的负载均衡，X轴扩展是扩展单体应用程序的常用方法。

Z轴扩展：根据请求的属性路由请求，Z轴扩展也需要运行单体应用程序的多个实例，但不同于X轴扩展，每个实例仅负责数据的一个子集

Y轴扩展：根据功能把应用拆分为服务，X轴和Z轴扩展有效地提升了应用的吞吐量和可用性，然而这两种方式都没有解决日益增长的开发问题和应用复杂性。为了解决这些问题，需要采用Y轴扩展，也就是功能性分解。Y轴扩展把一个单体应用分成了一组服务

2.SOA和微服务的比较

	SOA	微服务
服务间通信	智能管道，例如Enterprise Service Bus（ESB），往往采用重量级协议，例如SOAP或其他WS*标准	使用哑管道，例如消息代理，或者服务之间点对点通信，使用轻量级协议，例如REST或gRPC
数据管理	全局数据模型并共享数据库	每个服务都有自己的数据模型和数据库
典型服务的规模	较大的单体应用	较小的服务

3.微服务架构的好处

• 使大型的复杂应用程序可以持续交付和持续部署
• 每个服务都相对较小并容易维护
• 服务可以独立部署
• 服务可以独立扩展
• 微服务架构可以实现团队的自治
• 更容易实验和采纳新的技术
• 更好的容错性

4.微服架构的弊端

• 服务的拆分和定义是一项挑战
• 分布式系统带来的各种复杂性使开发，测试部署变得很困难
• 当部署跨越多个服务的功能时需要谨慎地协调更多的开发团队
• 开发者需要思考到底应该在应用的什么阶段使用微服务架构

微服务架构的模式语言

1.微服务架构并不是“银弹”

软件工程的世界里没有银弹

2.模式和模式语言

模式是针对特定上下文中发生的问题的可重用解决方案

软件模式通过定义一组互相协作的软件元素来解决软件架构或者设计问题

3.微服务架构的模式语言概括

微服务架构的模式语言事一组模式，可帮助架构师使用微服务架构构建应用程序，这些模式被分为了三组：

• 基础设施相关模式组：这些模式解决通常是在开发环节跟基础设施有关的问题。
• 应用基础设施相关模式组：这些模式解决应用层面的基础设施相关的问题。
• 应用相关模式组：这些模式解决开发人员面对的具体技术和架构问题。

4.微服务之上：流程和组织

对于大型和复杂的应用程序，微服务架构往往是最佳的选择，然而，除了拥有正确的架构之外，成功的软件开发还需要再组织、开发和交付流程方面做一些工作。

• 进行软件开发和交付的组织
• 进行软件开发和交付的流程
• 采用微服务架构时的人为因素