电子书：《微服务实践》《微服务实践》占hong来等译20190101
111
内容简介：
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基于令牌的.安.全.实践……9264组件(服务)测试4.1.4.安.全.性的责任6.5契约测试4.1.5编制风格的风险4.1.6微服务之间的通信6.5.2 spring cloud contract42与 openid的 oauth20一起6.6端到端测试·使用4.2.1 openid946.8小结4.2.2 oauth2.0第7章部署微服务4.2.3jwt4.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…159.5实施扩展策略前请三思75在 docker化的微服务中使用9.6微服务的监控和扩展工具………175开源ci工具第10章故障排除第8章演进现有系统10.1使用微服务时的常见问题8.1从哪里开始能下降1.1架构视角和最佳实践……1590.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志记录……1891.1如何设置并使用jing报……16810.23服务之间的依赖关系…1879..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故障隔离)在传统的单体架构中.如果出现这种问题(_内.存_泄漏).我们就需要重启整个应用包括其中的所有组件.也就是说整个系统会有一段死机时间
