标签分类 热门分类
当前位置:首页 > 行业软件及应用电子书 > 微服务电子书网盘下载
持续演进的Cloud Native:云原生架构下微服务最佳实践 持续演进的Cloud Native:云原生架构下微服务最佳实践
脚本之家

脚本之家 提供上传

资源
36
粉丝
5
喜欢
210
评论
9

    持续演进的Cloud Native:云原生架构下微服务最佳实践 PDF 高质量版

    微服务电子书
    • 发布时间:

    给大家带来的一篇关于微服务相关的电子书资源,介绍了关于Cloud、Native、云原生架构、微服务方面的内容,本书是由电子工业出版社出版,格式为PDF,资源大小187 MB,王启军编写,目前豆瓣、亚马逊、当当、京东等电子书综合评分为:9.1,更多相关的学习资源可以参阅 行业软件及应用电子书、等栏目。

  • 持续演进的Cloud Native:云原生架构下微服务最佳实践 PDF 下载
  • 下载地址:https://pan.baidu.com/s/18YdhxKYuUVzOBb9rHyEpt
  • 分享码:vfd8
  • 持续演进的Cloud Native:云原生架构下微服务最佳实践 PDF

    《持续演进的Cloud Native:云原生架构下微服务最佳实践》从架构、研发流程、团队文化三个角度详细介绍了如何构建Cloud Native。作者长期活跃在研发一线,具有丰富的架构设计经验,也曾亲身经历过很多失败的架构设计,如很多团队在实施微服务架构的时候,只强调拆分服务,根本没有理解微服务架构应该怎么做。《持续演进的Cloud Native:云原生架构下微服务*实践》就是想告诉读者,除了拆分服务,还要把哪些事做好,例如基础设施、一致性、性能、研发流程、团队文化等。

    《不断演变的Cloud Native:云原生态构架下微服务最好实践》共分成10 章,第1 章从总体上描述了Cloud Native 的渊源、构成及标准等;从第2 章到第7 章重中之重描述了微服务架构、灵巧基础设施建设及公共基础服务项目、易用性、可扩展性、性能、一致性等层面的设计方案实践;第8 章介绍了Serverless 和Service Mesh;第9 章介绍了怎样搭建产品研发步骤;第10 章介绍了怎样基本建设企业文化。

    这书希望给技术性管理人员、系统架构师和有一定基本的专业技术人员出示协助,非常是希望更改产品研发方式,从交货型手机软件衔接到云服务器的传统式软件行业开发人员,该书将协助你事半功倍。

    目录

    • 第1章  综述  1
    • 1.1  Cloud Native的起源  1
    • 1.2  Cloud Native的组成  4
    • 1.3  Cloud Native背后的诉求  5
    • 1.4  如何衡量Cloud Native的能力  5
    • 1.5  Cloud Native的原则  6
    • 第2章  微服务架构  11
    • 2.1  微服务架构的起源  11
    • 2.2  为什么采用微服务架构  12
    • 2.2.1  单体架构与微服务架构  12
    • 2.2.2  什么时候开始微服务架构  14
    • 2.2.3  如何决定微服务架构的拆分粒度  14
    • 2.3  微服务设计原则  15
    • 2.4  微服务架构实施的先决条件  17
    • 2.4.1  研发环境和流程上的转变  17
    • 2.4.2  拆分前先做好解耦  18
    • 2.5  微服务划分模式  20
    • 2.5.1  基于业务复杂度选择服务划分方法  20
    • 2.5.2  基于数据驱动划分服务  21
    • 2.5.3  基于领域驱动划分服务  22
    • 2.5.4  从已有单体架构中逐步划分服务  23
    • 2.5.5  微服务拆分策略  24
    • 2.5.6  如何衡量服务划分的合理性  25
    • 2.6  微服务划分反模式  26
    • 2.7  微服务API设计  28
    • 2.7.1  优秀API的设计原则  28
    • 2.7.2  服务间通信——RPC  28
    • 2.7.3  序列化——Protobuf  30
    • 2.7.4  服务间通信——RESTful  33
    • 2.7.5  通过Swagger实现RESTful  36
    • 2.7.6  通过Spring Boot、Springfox、Swagger实现RESTful  41
    • 2.7.7  HTTP协议的进化——HTTP/2  46
    • 2.7.8  HTTP/2和Protobuf的组合——gRPC  48
    • 2.8  微服务框架  53
    • 2.9  基于Dubbo框架实现微服务  54
    • 2.10  基于Spring Cloud框架实现微服务  58
    • 2.11  服务发现场景下的ZooKeeper与Etcd  67
    • 2.12  微服务部署策略  68
    • 2.12.1  服务独享数据库  69
    • 2.12.2  服务独享虚拟机/容器  70
    • 2.13  为什么总觉得微服务架构很别扭  70
    • 第3章  敏捷基础设施及公共基础服务  73
    • 3.1  传统基础设施面临的挑战  73
    • 3.2  什么是敏捷基础设施  74
    • 3.3  基于容器的敏捷基础设施  75
    • 3.3.1  容器VS虚拟机  76
    • 3.3.2  安装Docker  77
    • 3.3.3  部署私有Docker Registry  79
    • 3.3.4  基于Spring Boot、Maven、Docker构建微服务  79
    • 3.3.5  基于docker-compose管理容器  84
    • 3.4  基于公共基础服务的平台化  85
    • 3.5  监控告警服务  86
    • 3.5.1  监控数据采集  87
    • 3.5.2  监控数据接收模式  87
    • 3.5.3  通过时间序列数据库存储监控数据  88
    • 3.5.4  开源监控系统实现Prometheus  88
    • 3.5.5  通过Prometheus和Grafana监控服务  90
    • 3.6  分布式消息中间件服务  96
    • 3.6.1  分布式消息中间件的作用  97
    • 3.6.2  业界常用的分布式消息中间件  98
    • 3.6.3  Kafka的设计原理  99
    • 3.6.4  为什么Kafka性能高  100
    • 3.6.5  Kafka的数据存储结构  102
    • 3.6.6  如何保证Kafka不丢消息  104
    • 3.6.7  Kafka跨数据中心场景集群部署模式  106
    • 3.7  分布式缓存服务  108
    • 3.7.1  分布式缓存的应用场景  109
    • 3.7.2  业界常用的分布式缓存Memcached  110
    • 3.7.3  业界常用的分布式缓存——Redis  111
    • 3.7.4  Redis常用的分布式缓存集群模式  112
    • 3.7.5  基于Codis实现Redis分布式缓存集群  116
    • 3.8  分布式任务调度服务  118
    • 3.8.1  通过Tbschedule实现分布式任务调度  119
    • 3.8.2  通过Elastic-Job实现分布式任务调度  123
    • 3.9  如何生成分布式ID  126
    • 3.9.1  UUID  126
    • 3.9.2  SnowFlake  127
    • 3.9.3  Ticket Server  128
    • 3.9.4  小结  129
    • 第4章  可用性设计  130
    • 4.1  综述  130
    • 4.1.1  可用性和可靠性的关系  130
    • 4.1.2  可用性的衡量标准  131
    • 4.1.3  什么降低了可用性  131
    • 4.2  逐步切换  132
    • 4.2.1  影子测试  132
    • 4.2.2  蓝绿部署  133
    • 4.2.3  灰度发布/金丝雀发布  134
    • 4.3  容错设计  135
    • 4.3.1  消除单点  136
    • 4.3.2  特性开关  136
    • 4.3.3  服务分级  137
    • 4.3.4  降级设计  138
    • 4.3.5  超时重试  139
    • 4.3.6  隔离策略  152
    • 4.3.7  熔断器  153
    • 4.4  流控设计  157
    • 4.4.1  限流算法  157
    • 4.4.2  流控策略  159
    • 4.4.3  基于Guava限流  160
    • 4.4.4  基于Nginx限流  162
    • 4.5  容量预估  163
    • 4.6  故障演练 164
    • 4.7  数据迁移  165
    • 4.7.1  逻辑分离,物理不分离  166
    • 4.7.2  物理分离  166
    • 第5章  可扩展性设计  168
    • 5.1  加机器能解决问题吗  168
    • 5.2  横向扩展  169
    • 5.3  AKF扩展立方体  170
    • 5.4  如何扩展长连接  172
    • 5.5  如何扩展数据库  175
    • 5.5.1  X轴扩展——主从复制集群  175
    • 5.5.2  Y轴扩展——分库、垂直分表  176
    • 5.5.3  Z轴扩展——分片(sharding)  177
    • 5.5.4  为什么要带拆分键  182
    • 5.5.5  分片后的关联查询问题  183
    • 5.5.6  分片扩容(re-sharding)  184
    • 5.5.7  精选案例  187
    • 5.6  如何扩展数据中心  190
    • 5.6.1  两地三中心和同城多活  190
    • 5.6.2  同城多活  191
    • 5.6.3  异地多活  192
    • 第6章  性能设计  194
    • 6.1  性能指标  195
    • 6.2  如何树立目标  195
    • 6.3  如何寻找平衡点  196
    • 6.4  如何定位瓶颈点  197
    • 6.5  服务通信优化  198
    • 6.5.1  同步转异步  198
    • 6.5.2  阻塞转非阻塞  199
    • 6.5.3  序列化  200
    • 6.6  通过消息中间件提升写性能  201
    • 6.7  通过缓存提升读性能  202
    • 6.7.1  基于ConcurrentHashMap实现本地缓存  203
    • 6.7.2  基于Guava Cache实现本地缓存  204
    • 6.7.3  缓存的常用模式  205
    • 6.7.4  应用缓存的常见问题  207
    • 6.8  数据库优化  208
    • 6.8.1  通过执行计划分析瓶颈点  208
    • 6.8.2  为搜索字段创建索引  209
    • 6.8.3  通过慢查询日志分析瓶颈点  210
    • 6.8.4  通过提升硬件能力优化数据库  211
    • 6.9  简化设计  212
    • 6.9.1  转移复杂度  212
    • 6.9.2  从业务角度优化  212
    • 第7章  一致性设计  214
    • 7.1  问题起源  214
    • 7.2  基础理论  215
    • 7.2.1  什么是分布式事务  216
    • 7.2.2  CAP定理  218
    • 7.2.3  BASE理论  219
    • 7.2.4  Quorum机制(NWR模型)  219
    • 7.2.5  租约机制(Lease)  220
    • 7.2.6  状态机(Replicated State Machine)  221
    • 7.3  分布式系统的一致性分类  222
    • 7.3.1  以数据为中心的一致性模型  223
    • 7.3.2  以用户为中心的一致性模型  226
    • 7.3.3  业界常用的一致性模型  229
    • 7.4  如何实现强一致性  230
    • 7.4.1  两阶段提交  230
    • 7.4.2  三阶段提交(3PC)  231
    • 7.5  如何实现最终一致性  232
    • 7.5.1  重试机制  232
    • 7.5.2  本地记录日志  233
    • 7.5.3  可靠事件模式  233
    • 7.5.4  Saga事务模型  235
    • 7.5.5  TCC事务模型  237
    • 7.6  分布式锁  238
    • 7.6.1  基于数据库实现悲观锁和乐观锁  239
    • 7.6.2  基于ZooKeeper的分布式锁  241
    • 7.6.3  基于Redis实现分布式锁  242
    • 7.7  如何保证幂等性  244
    • 7.7.1  幂等令牌(Idempotency Key)  244
    • 7.7.2  在数据库中实现幂等性  246
    • 第8章  未来值得关注的方向  247
    • 8.1  Serverless  247
    • 8.1.1  什么是Serverless  247
    • 8.1.2  Serverless的现状  248
    • 8.1.3  Serverless的应用场景  249
    • 8.2  Service Mesh  250
    • 8.2.1  什么是Service Mesh  250
    • 8.2.2  为什么需要Service Mesh  252
    • 8.2.3  Service Mesh的现状  253
    • 8.2.4  Istio架构分析  255
    • 第9章  研发流程  258
    • 9.1  十二因子  258
    • 9.2  为什么选择DevOps  261
    • 9.3  自动化测试  263
    • 9.3.1  单元测试  263
    • 9.3.2  TDD  264
    • 9.3.3  提交即意味着可测试  265
    • 9.4  Code Review  265
    • 9.4.1  Code Review的意义  265
    • 9.4.2  Code Review的原则  266
    • 9.4.3  Code Review的过程  267
    • 9.5  流水线  267
    • 9.5.1  持续交付  267
    • 9.5.2  持续部署流水线  268
    • 9.5.3  基于开源打造流水线  268
    • 9.5.4  Amazon的流水线  271
    • 9.5.5  开发人员自服务  271
    • 9.6  为什么需要AIOps  272
    • 9.7  基于数据和反馈持续改进  273
    • 9.8  拥抱变化  274
    • 9.9  代码即设计  274
    • 第10章  团队文化  276
    • 10.1  为什么团队文化如此重要  276
    • 10.2  组织结构  278
    • 10.2.1  团队规模导致的问题  278
    • 10.2.2  康威定律  278
    • 10.2.3  扁平化的组织  279
    • 10.2.4  独裁的管理方式还是民主的管理方式  280
    • 10.2.5  民主的团队如何做决策  282
    • 10.3  环境氛围  282
    • 10.3.1  公开透明的工作环境  282
    • 10.3.2  学习型组织  283
    • 10.3.3  减少正式的汇报  284
    • 10.3.4  高效的会议  284
    • 10.3.5  量化指标致死  286
    • 10.4  管理风格  287
    • 10.4.1  下属请假你会拒绝吗  287
    • 10.4.2  为什么你招不到你想要的人  288
    • 10.4.3  得到了所有人的认可,说明你并不是一个好的管理者  291
    • 10.4.4  尽量避免用自己的权力去做决策  291
    • 10.4.5  一屋不扫也可助你“荡平天下”  292
    • 10.4.6  如何留下你想要的人293
    • 10.5  经典案例  294
    • 10.5.1  Instagram的团队文化  294
    • 10.5.2  Netflix的团队文化  294

    上一篇:一路编程  下一篇:Julia数据科学应用

    展开 +

    收起 -

    微服务 相关电子书
    关于微服务的学习笔记
    网友NO.715234

    详解Spring Cloud微服务架构下的WebSocket解决方案

    WebSocket在现代浏览器中的应用已经算是比较普遍了,在某些业务场景下,要求必须能够在服务器端推送消息至客户端。在没有WebSocket的年代,我们使用过dwr,在那个时候dwr真实一个非常棒的方案。但是在WebSocket兴起之后,我们更愿意使用标准实现来解决问题、 首先交代一下,本篇文章不讲解WebSocket的配置,主要讲的是针对在微服务架构集群模式下解决方案的选择。 微服务架构大家应该都不陌生了,在微服务架构下,服务是分布式的,而且为了保证业务的可用性,每个服务都是以集群的形式存在。在集群模式下,要保证集群的每一个节点的访问得到相同的结果就需要做到数据一致性,如缓存、session等。 微服务集群缓存通常使用分布式缓存redis解决,session一致性也通常会通过redis解决,但是现在更流行的是无状态的Http,即无session化,最常见的解决方案就是OAuth。 WebSocket有所不同,它是与服务端建立一个长连接,在集群模式下,显然不可能把前端与服务集群中的每一个节点建立连接,一个可行的思路是像解决http session的共享一样,通过redis来实现websocket的session共享,但是websocket session的数量是远多于http session的数量的(因为每打开一个页面都会建立一个websocket连接),所以随着用户量的增长,共享的数据量太大,很容易造成……

    网友NO.831579

    详解SpringCloud微服务架构之Hystrix断路器

    一:什么是Hystrix 在分布式环境中,许多服务依赖项中的一些将不可避免地失败。Hystrix是一个库,通过添加延迟容差和容错逻辑来帮助您控制这些分布式服务之间的交互。Hystrix通过隔离服务之间的访问点,停止其间的级联故障以及提供回退选项,从而提高系统的整体弹性。 Hystrix旨在执行以下操作 1:对通过第三方客户端库访问(通常通过网络)的依赖关系提供保护并控制延迟和故障。 2:隔离复杂分布式系统中的级联故障。 3:快速发现故障,尽快恢复。 4:回退,尽可能优雅地降级。 5:启用近实时监控,警报和操作控制。 二:为什么需要Hystrix? 大型分布式系统中,一个客户端或者服务依赖外部服务,如果一个服务宕了,那么由于我们设置了服务调用系统超时时间,势必会影响相应时间,在高并发的情况下大多数服务器的线程池就出现阻塞(BLOCK),影响整个线上服务的稳定性。 (图片官方图片) 当一切都健康时,请求可以看起来像这样 当许多后端服务系统中的一个宕掉时,整个用户请求: 如果多个客户端调用同一个异常服务的时候,出现的情况是: 三:Hystrix解决什么问题? 分布式架构中的应用程序具有几十个依赖关系,每个依赖关系在某个时刻将不可避免的出现异常。如果应用程序不与这些外部故障隔离,则可能出现线……

    网友NO.884368

    浅谈Spring Cloud下微服务权限方案

    背景 从传统的单体应用转型Spring Cloud的朋友都在问我, Spring Cloud 下的微服务权限怎么管?怎么设计比较合理?从大层面讲叫服务权限,往小处拆分,分别为三块: 用户认证 、 用户权限 、 服务校验 。 用户认证 传统的单体应用可能习惯了session的存在,而到了Spring cloud的微服务化后,session虽然可以采取分布式会话来解决,但终究不是上上策。开始有人推行Spring Cloud Security结合很好的 OAuth2 ,后面为了优化OAuth 2中 Access Token 的存储问题,提高后端服务的可用性和扩展性,有了更好Token验证方式 JWT (JSON Web Token)。这里要强调一点的是, OAuth2 和 JWT 这两个根本没有可比性,是两个完全不同的东西。 OAuth2是一种授权框架 ,而 JWT 是一种认证协议 OAuth2认证框架OAuth2中包含四个角色: 资源拥有者(Resource Owner) 资源服务器(Resource Server) 授权服务器(Authorization Server) 客户端(Client) OAuth2包含4种授权模式 授权码(认证码)模式 (Authorization code) 简化(隐形)模式 (Impilict 用户名密码模式 (Resource Owner Password Credential) 客户端模式 (Client Credential) 其中,OAuth2的运行流程如下图,摘自RFC 6749: +--------+ +---------------+| |--(A)- Authorization Request -| Resource || | | Owner || |-(B)-- Authorization Grant ---| || | +---------------+| || | +---------------+| |--(C)-- Authorization Grant -……

    网友NO.839270

    了解java架构之微服务架构—雪崩效应

    前言 微服务化产品线,每一个服务专心于自己的业务逻辑,并对外提供相应的接口,看上去似乎很明了,其实还有很多的东西需要考虑,比如:服务的自动扩充,熔断和限流等,随着业务的扩展,服务的数量也会随之增多,逻辑会更加复杂,一个服务的某个逻辑需要依赖多个其他服务才能完成。 一但一个依赖不能提供服务很可能会产生雪崩效应,最后导致整个服务不可访问。 微服务之间进行rpc或者http调用时,我们一般都会设置调用超时,失败重试等机制来确保服务的成功执行,看上去很美,如果不考虑服务的熔断和限流,就是雪崩的源头。 假设我们有两个访问量比较大的服务A和B,这两个服务分别依赖C和D,C和D服务都依赖E服务 A和B不断的调用C,D处理客户请求和返回需要的数据。当E服务不能供服务的时候,C和D的超时和重试机制会被执行 由于新的调用不断的产生,会导致C和D对E服务的调用大量的积压,产生大量的调用等待和重试调用,慢慢会耗尽C和D的资源比如内存或CPU,然后也down掉。 A和B服务会重复C和D的操作,资源耗尽,然后down掉,最终整个服务都不可访问。 常见的导致雪崩的情况有以下几种: 程序bug导致服务不可用,或者运行缓慢 缓存击穿,导致调用全部访问某服务,导致down掉 访问量的突然激增。 硬件问题……

    Copyright 2018-2019 xz577.com 码农之家

    版权责任说明