《微服务架构设计模式》读书笔记
看看了书评，挺好的，刷一下，嘻嘻….生活加油！！！
写在前面
- 看看了书评，挺好的，刷一下，嘻嘻….
更新中…
傍晚时分，你坐在屋檐下，看着天慢慢地黑下去，心里寂寞而凄凉，感到自己的生命被剥夺了。当时我是个年轻人，但我害怕这样生活下去，衰老下去。在我看来，这是比死亡更可怕的事。——–王小波[这里写一句鼓励自己的话,可以加一个颜色(可选)]
第1章逃离单体地狱
1.1 迈向单体地狱的漫长旅程
单体应用,由一个单一的Java WAR (Web Application Archive)文件构成。随着时间的推移,这个文件变成了一个庞大的、复杂的应用程序。,已成为“泥球模式“ (the Big Ball of Mud Pattern, www.laputan.org/mud/)的一个典型例子。“`随意架构的、庞大的、草率的、布满了胶带和线路,如同意大利面条一般的代码丛林`”。
软件交付的步伐已经放缓。更糟糕的是,应用程序是使用一些日益过时的框架编写的。
1.1.1 FTGO应用程序的架构
FTGO应用程序是一个典型的分层模块化企业级Java应用。FTGO应用程序拥有一个六边形的架构。在这个六边形中,应用程序的核心是业务逻辑组件。在业务逻辑外围是各种用来实现用户界面和与外部服务集成的适配器。
业务逻辑由包含了服务和领域对象的模块组成,一些典型的模块包括OrderManagement, Delivery Management, Billing和Paymentse。若干适配器用来完成与外部系统的对接工作,一些是入站( inbound)适配器,它通过调用业务逻辑来处理各类请求,包括REST API和Web用户界面适配器。其他是出站(outbound)适配器.
1.1.2单体架构的好处
- 应用的开发很简单: IDE和其他开发工具只需要构建这一个单独的应用程序。
- 易于对应用程序进行大规模的更改:可以更改代码和数据库模式,然后构建和部署。
- 测试相对简单直观:开发者只需要写几个端到端的测试,启动应用程序,调用RESTAPI,然后使用Selenium。这样的工具测试用户界面。
- 部署简单明了:开发者唯一需要做的,就是把WAR文件复制到安装了Tomcat的服务器上。
- 横向扩展不费吹灰之力: FTGO可以运行多个实例,由一个负载均衡器进行调度。
1.1.3什么是单体地狱
- 过度的复杂性会吓退开发者
- 开发速度缓慢
- 从代码提交到实际部署的周期很长,而且容易出问题
- 难以扩展
- 交付可靠的单体应用是一项挑战
- 需要长期依赖某个可能已经过时的技术栈
1.2 为什么本书与你有关
1.3 你会在本书中学到什么
读完这本书后,你会理解和掌握如下知识:
- 微服务架构的基本特点,它的好处和弊端,以及应该在什么情况下使用微服务架构。
- 分布式数据管理的架构模式。
- 针对微服务架构应用程序的有效测试策略。
- 微服务架构应用程序的部署方式。
- 把单体应用重构为微服务架构的策略。
你也会掌握如下技术:
- 使用微服务的架构模式来设计应用程序的架构。
- 为服务开发业务逻辑。使用Saga在进程间维护数据的一致性。
- 实现跨服务的数据查询。
- 更高效地测试微服务架构应用程序。
- 开发生产环境就绪的应用程序,实现安全性、可配置性和可观测性。
- 把现有的单体应用重构为服务。
1.4 拯救之道:微服务架构
1.4.1扩展立方体和服务
这个模型描述了扩展一个应用程序的三种维度: X、Y和Z,
X轴扩展:
在多个实例之间实现请求的负载均衡，X轴扩展是扩展单体应用程序的常用方法。
x轴扩展的工作原理。在负载均衡器之后运行应用程序的多个实例。负载均衡器在N个相同的实例之间分配请求。这是提高应用程序吞吐量和可用性的好方法。
Z轴扩展:
根据请求的属性路由请求Z轴扩展也需要运行单体应用程序的多个实例,但不同于X轴扩展,每个实例仅负责数据的一个子集。
Z轴扩展的工作原理。置于前端的路由器使用请求中的特定属性将请求路由到适当的实例。例如,应用程序可能会使用请求中包含的userId来路由请求。在这个例子中,每个应用程序实例负责一部分用户。该路由器使用请求Authorization头部指定的user1d来从N个相同的应用程序实例中选择一个。对于应用程序需要处理增加的事务和数据量时, Z轴扩展是一种很好的扩展方式。
y轴扩展:
根据功能把应用拆分为服务，X轴和Z轴扩展有效地提升了应用的吞吐量和可用性,然而这两种方式都没有解决日益增长的开发问题和应用复杂性。为了解决这些问题,我们需要采用Y轴扩展,也就是功能性分解。丫轴扩展把一个单体应用分成了一组服务
服务本质上是一个麻雀虽小但五脏俱全的应用程序,它实现了一组相关的功能,例如订单管理、客户管理等。服务可以在需要的时候借助X轴或Z轴方式进行扩展。例如,订单服务可以被部署为一组负载均衡的服务实例。
我对微服务架构的概括性定义是:把应用程序功能性分解为一组服务的架构风格。请.注意这个定义中并没有包含任何与规模有关的内容。重要的是,每一个服务都是由一组专注的、内聚的功能职责组成。
1.4.2 微服务架构作为模块化的一种形式
模块化是开发大型、复杂应用程序的基础。微服务架构使用服务作为模块化的单元。服务的API为它自身构筑了一个不可逾越的边界,你无法越过API去访问服务内部的类,这与采用Java包的单体应用完全不同。因此模块化的服务更容易随着时间推移而不断演化。微服务架构也带来其他的好处,例如服务可以独立进行部署和扩展。
1.4.3每个服务都拥有自己的数据库
微服务架构的一个关键特性是每一个服务之间都是松耦合的,它们仅通过API进行通信。实现这种松耦合的方式之一,是每个服务都拥有自己的私有数据库。对于一个线上商店来说, Order service拥有一个包括ORDERS表的数据库, customer Service服务拥有一个包含CUSTOMERS表的数据库。在开发阶段,开发者可以修改自己服务的数据库模式,而不必同其他服务的开发者协调。在运行时,服务实现了相互之间的独立。服务不会因为其他的服务锁住了数据库而进入堵塞的状态。
1.4.4 FTGO的微服务架构
1.4.5 微服务架构与SOA的异同
1.5 微服务架构的好处和弊端
1.5.1微服务架构的好处
微服务架构有如下好处:
- 使大型的复杂应用程序可以持续交付和持续部署。
- 每个服务都相对较小并容易维护。
- 服务可以独立部署。
- 服务可以独立扩展。
- 微服务架构可以实现团队的自治。
- 更容易实验和采纳新的技术。
- 更好的容错性。
1.5.2 微服务架构的弊端
微服务架构的主要弊端和问题如下:
- 服务的拆分和定义是一项挑战。
- 分布式系统带来的各种复杂性,使开发、测试和部署变得更困难。
- 当部署跨越多个服务的功能时需要谨慎地协调更多开发团队。
- 开发者需要思考到底应该在应用的什么阶段使用微服务架构。
1.6微服务架构的模式语言
一个用来表述多种架构设计的选择方案,并且可用来改进决策的方式,就是使用模式语言
1.6.1微服务架构并不是“银弹”
1.6.2模式和模式语言
模式是针对特定上下文中发生的问题的可重用解决方案。
常用的模式结构包括三个重要部分:
- 需求(Forces):
- 结果上下文(Resulting context):
- 相关模式(Related patterns):
