多种网盘链接检测插件 购买前，请先检测网盘链接是否有效
《微服务实践》_占红来等译_2019-01-01_1
《微服务实践》_占红来等译_2019-01-01_2
《微服务实践》_占红来等译_2019-01-01_3
内容简介：
5.3SOA中的数据模型
第3章微服务端点之间的通信
5.4微服务架构中的数据模型
3.1微服务间应该如何通信
5.4.1每个微服务限定一些
3.2.1编制
54.2每个微服务一个数据库
2.2编排
54.3Saga模式
同步通信和异步通信
544必要时采用混合数据
3.3.1同步通信
3.3.2异步通信
5.5从单体应用向微服务迁移数据
3.33财务服务
55.2数据模型迁移方式
第4章微服务端点的.安.全.
1微服务的.安.全.挑战
4.1.1复合技术栈或者存在遗留
61微服务中测试的目的
4.1.2认证和授权(访问
62单元测试
63集成测试
4.13基于令牌的.安.全.实践……92
64组件(服务)测试
4.1.4.安.全.性的责任
6.5契约测试
4.1.5编制风格的风险
4.1.6微服务之间的通信
6.5.2 Spring Cloud Contract
42与 OpenID的 OAuth20一起
6.6端到端测试·
使用
4.2.1 OpenID
946.8小结
4.2,2 OAuth2.0
第7章部署微服务
4.2.3JWT
4.2.4示例应用
7.1持续集成
4.3小结
持续交付
第5章创建高效的数据模型
73用微服务配置C1和CD工具…140
化
5.1数据和建模
5.2单体架构中的数据模型
42 Docker引擎
7.4.3 Docker镜像
9.1.4监控前门流量
7.4.4 Docker存储
9.2监控模式的发展变化
74.5应用程序在 Docker中是
93ri志记录有助于监控
如何工作的
94微服务系统的扩展原则
74.6公共、私有和官方的
镜像库
94.3z轴
48在 Linux中安装 Docker…15
9.5实施扩展策略前请三思
75在 Docker化的微服务中使用
9.6微服务的监控和扩展工具………175
开源CI工具
第10章故障排除
第8章演进现有系统
10.1使用微服务时的常见问题
8.1从哪里开始
能下降
1.1架构视角和最佳实践……159
0.1.2ri志记录位置因编程
8..2数据库视角和最佳实践…162
语言而异
2示例应用及其演变过程
多组件之间的耦合或
82.1用户管理服务
依賴问题
82.2购物车/订单服务
0.1.4服务部署数量与ri
支付服务
俱增……
8.2.4配送/跟踪服务和通信
1.5监控多项服务,发现性能
产品推荐服务
0.1.6ri志与不同组件的
关系
10.2常见问题的解决方法
10.2.1解决性能问题的步骤…186
第9章微服务的监控和扩展
022处理不同语言生成的并处于
9.1微服务系统的监控原则
不同位置的ri志记录……18
91.1如何设置并使用jing报……168
10.23服务之间的依赖关系…187
9..2从一开始做好监控和发布
0.24 DevOps专家积极参与…187
渠道规划
10.2.5监控…
9.1.3自动扩展和自动发现……16810.3小结
第1章
微服务架构简介
软件架构可以定义为系统设计的一组规则和原则,它定义了软件系统的元素、行为
结构和不同组件之间的关系
在20世纪80年代初期,出现了一些大型软件系统,亟需一种统一的模式(也就是
后来的架构〕来解决设计这些庞大系统所面临的一些常见问题。从那时开始,演化出了
天我们所熟知的“软件架构”的概念。自此之后,很多架构类型被引入到大型软件系
统的设计当中。细细数来,软件行业已经见证了从不共享架构( shared nothing),到单体
架构( monolithic),到客户服.务.器架构( client-server),到分布式多层架构( n-tire),再
到面向服务架构( service- oriented architecture,SOA)等架构风格。微服务架构无疑就是
这条演化链上的一个新节点。
近年来,微服务这个词的热度在各种软件开发者/架构师社区中呈指数级增长
我们经常听到一些采用了单体架构的组织抱怨发布周期太长、调试烦琐、维护成本
高、扩容难等问题。这些问题罄竹难书,以至于即使是少数管理得很好的单体应用也
需要花费大量的人力物力来解决这些问题。微服务为解决这些问题提供了一种高效的
办法,这也毫无疑问是其ri益火热的原因之
言以蔽之,微服务架构可以把
很大、很复杂的问题分解成一系列相对较小的服务,并且每个服务只负责自己分管的
那一部分。
微服务架构的基本哲理是:只做一件事,并把它做到极致
微服务的核心是单一职责原则( Single Responsibility Principle,SRP)。在微服务架
构中,大的业务块会被拆分为一些小的任务,每一个小的任务都依托于一个微服务来
完成。在微服务架构的系统中,微服务的数量可多可少,取决于业务需求以及任务被
拆分的情况。微服务架构可以给组织带来很多单体架构所没有的好处,但是同时,微
服务架构也有自己的一些问题需要解决。我们会在接下来的章节中继续讨论微服务架
构的优势和短板
第1章徵服务架构简介
1.1常规微服务架构
微服务架构的灵感来自面向服务架构(SOA)。微服务架构没有什么黄金法则,如果
我们观摩一下现在软件行业中实现的这些不同的微服务架构,就会发现每项应用都有自
的不同风格的微服务架构。关于微服务,并没有完美或标准化的清晰定义。但是总的
来说,我们可以通过一些特征和原则归纳出微服务架构
1.2微服务架构的特征
任何呈现出下面这6个原则和特征的架构都可以划归微服务架构的范畴
系统由两个及以上运行单元或组件组成。这些组件将其自身功能以服务的形式展
出来。每个组件服务于一个业务目标,各个组件之间是松耦合的。组件之间按
照预先定义的协议进行交互,协议包括消息队列、HTTP请求响应模型等
系统应该是与編程语言无关的,某一个组件可以用Java开发,与此同时另外
个组件可以用NET开发。单独某一个服务在实现时的技术选型应该不会影响到
整个应用的架构
系统的数据库应该是去中心化的。理想情况下,每个微服务应该享有自己的数据
库,该数据库仅供该服务自己使用,任何其他组件或者服务都不能提取或者修改
该数据库中的数据
系统中的每个组件都应该是内聚、独立且可以自行部署的。任何一个组件在正常
工作和部署的时候都不应该依赖其他组件或者资源。为了实现快速上线,每个组
件应该有自己的持续集成/持续部署(CICD)流水线
系统应该有自动化测试。微服务架构最值得称道的特征就是快,在构建、测试到上
线的整个周期中,如果没有自动化测试,速度快就是一纸空谈
任何一个组件/服务的故障都应该是隔离的。单个服务的故障不应该拖垮整个应
用,也不应该影响其他组件和服务。为了做到这一点,应该有一些故障回滚的机
制。意思是说,如果某个服务出现了故障,它应该能够很容易地回滚到之前的
个能正常工作的版本
下面我们举个简单的例子来具象化我们所说的这些原则
12.1问题定义
假设我们需要一个能根据注册用户的权限生成打折优惠的在线购物应用。对于铂金
1.2徵服务架构的特征
用户打八折,黄金用户八五折,白银用户九折,普通访客九
12.2解决方案
在这个架构中,我们有两个微服务。第一个服务用来验证用户权限,这个服务需要
接受用户登.录时的认证信息,然后将用户的权限等级作为应答返还给消费者。第二个服
务接受一个权限等级,然后按照用户的购物车(购物车本身应该是另外一个服务)返回
适用的折扣比例
在图1-1所示的架构图中,有两个组件,它们分别有各自对应的数据库。假设这两个
组件都以REST接口的形式公开其服务。消费者可以在认证服务MS1中通过登.录认证信
息得到用户的详细信息,包括用户的杈限等级,然后可以在第二个折扣服务MS2中,通
过权限等级得到折扣百分比
认证服务
消费者
该解决方案贴合了哪些微服务架构的原则
每个服务只为一个业务目的服务(原则1)。每个服务可以是不同平台的,相互之间
无影响(原则2)。每个微服务都有自己独享的数据库(原则3)。多个服务之间是相互独
立的,也就是说它们不共享各自的数据库,并且可以各自独立部署(假设已经有了相应
的CICD流水线,也就是原则4)。
现在我们假设在某些极少数的情况下,认证服务MS1由于运行时异常或者_内.存_泄漏
挂掉,此时消费者在访问认证服务时,会得到404的HTTP状态码响应。404(未找
到)会被消费者理解成该用户在数据库中不存在,此时消费者会将该用户理解为普通访
着就会按照普通访客的方式计算折扣。也就是说,系统始终处于运行状态。认
证服务MS1故障并没有危害其他正在运行的服务(对应原则6故障隔离)
在传统的单体架构中,如果出现这种问题(_内.存_泄漏),我们就需要重启整个应用
包括其中的所有组件,也就是说整个系统会有一段死机时间
|
|
