在过去5年中，微服务架构风格变得越来越流行。且不论公司规模多大，单就工程团队来说，微服务也变得越来越可行。当今，微服务已经不是概念，而是势不可挡的潮流，它在大型互联网电商类企业已有丰富的实践案例，效果很好。但对于其他有志于向微服务架构转型的技术爱好者，微服务如何落地还存在很多不清楚的地方，为了帮助大家更好地了解微服务，且带领大家走进微服务之门。
今天小编就给大家分享一份腾讯大佬总结出来的500+页微服务架构学习宝典分享给大家!通过学习本文档读者将了解如何进行微服务应用的开发和部署、如何通过微服务来实现有效的持续交付，以及如何用Kubernetes、Docker和GoogleContainerEngine开发实例。
主要内容
第1章微服务的设计与运行；
第2章SimpleBank公司的微服务；
微服务非常适合于有多维复杂性的系统，比如产品的供应范围、全球部署和监管压力。在设计微服务时，了解产品业务领域是至关重要的。服务交互可以是编配型的，也可以是编排型的。后者会增加系统复杂度，但是能够降低系统中服务之间的耦合度。API网关是一-种常见的模式，它将微服务架构的复杂性进行了封装和抽象，所以前端或者外部消费者不需要考虑这部分复杂度。如果开发者充分信任自己的服务能够处理生产环境上的流量压力，就可以说这个服务是生产就绪的。如果开发者可以可靠地部署和监控某个服务，就可以对这个服务更有信心。服务监控应该包括日志聚合以及服务层次的健康检查。微服务会因硬件、通信以及依赖项等原因而出现故障,并不是只有代码中的缺陷才会导致故障发生。收集业务指标、日志以及服务间的链路跟踪记录对于了解微服务应用当前和过去的运行表现是至关重要的。随着微服务以及支持团队的数量的不断增加，技术分歧以及孤立会日渐成为技术团队的挑战。避免技术分歧和孤立需要在不同团队间采用相似的标准和最佳实践，不管采用何种技术基础。
第3章微服务应用的架构；
单独来讲，微服务的内部和单体应用是相似的。微服务应用就像一个街区:它最终的样子不是指定好的，而是由一系列的准则和高层的概要模型来指导实现的。指导微服务架构的准则会反映出组织的目标并对团队的实践产生影响。架构规划应该促进良性发展，而不是强行指定整个应用的方案。微服务应用是由四层组成的:平台层、服务层、边界层和客户端层。平台层提供了一系列的工具和基础设施来支持开发面向生产的服务。在微服务应用中，同步通信通常是第一选择,并且它非常适合命令型的交互，但是也存在缺点一会增加耦合性和不稳定性。异步通信更加灵活，能够适应快速的系统演化，付出的代价是复杂度增加。常见的异步通信模式包括队列和发布-订阅。边界层就是微服务应用的一个门面，对于外部消费者来说，这是非常适合的。常见的边界层模式有API网关和消费者驱动的网关。客户端应用，比如网站和移动端应用，通过边界层与移动后端进行交互。客户端有越来越臃肿庞大的风险，但是现在也开始出现--些将微服务原则应用于前端应用的技术。
第4章新功能设计；
了解业务问题一识别实体和用例一划分服务责任，我们可以通过这一流程来划定服务范围。可以采用不同的方式来对服务进行划分:按业务功能划分、按用例划分和按易变性划分。读者可以综合运用这些方法。好的划分决策能够让服务满足微服务的三大关键特性:只负责单-职责、可替换和可独立部署。限界上下文通常是与服务边界相对应的，在思考服务的未来发展时,这是一一种很有效的方法。通过对易变领域的深入思考，开发者可以将那些会--起变化的领域封装起来，以提高应对未来变化的适应能力。如果服务划分不好，后期修正的代价是特别大的，因为到那时，开发者需要重构多个代码库，由此产生的工作量会变得特别大。我们也可以将技术功能封装成一个服务,这么做既能够简化业务能力，又可以对业务功能提供支撑，并能最大限度地提高服务的可用性。如果服务边界还不够明确，我们宁可选择粗粒度的服务，但是要主动在服务内部采用模块化的方案来为未来的拆分做准备。服务下线是一件特别有挑战性的工作，但是随着微服务应用的不断发展,我们未来终有一天会需要这么做。在大型组织机构中，将所有权拆分到多个团队中是很有必要的，但是这又会引入新的问题:控制变弱、设计受限、开发速度不一致。代码开放化、接口明确化、沟通持续化以及放宽对DRY原则的要求都可以缓解团队之间的紧张关系。
第5章微服务的事务与查询；
在跨服务的交互中实现ACID特性是很困难的，微服务需要采用不同的方式来实现一致性。类似两阶段提交这样的协调方案会引入加锁操作，扩展性不好。基于事件的架构可以解除各个独立组件之间的耦合,并为微服务应用的业务逻辑和查询的可扩展性打下基础。倾向于高可用，而非-一-致性，这会使得架构的可扩展性更强。Saga是由--组消息驱动的、独立的本地事务组成的全局操作。它们通过补偿操作来回滚错误的状态，以实现--致性。在构建反映现实世界环境的微服务时，预见失败场景并做好准备是非常重要的一部分内容，操作的隔离性反而没那么至关重要。我们通常通过组合多个API的结果来实现跨多个微服务的查询功能。高效的复合型查询应该采用CQRS模式来实现一套独立的读数据模型，特别是在那些查询模式需要采用另-一种数据存储系统时。
第6章设计高可靠服务；
在复杂的分布式系统中，故障是不可避免的一在设计这些系统时，开发者必须考虑容错能力。每个服务的可用性都会对整个应用的可用性的产生影响。对每个应用制定合适的策略来减轻故障的风险，这需要仔细考虑故障的频次、影响以及减少这些罕见的故障事件所增加的成本。大部分故障发生在4个领域:硬件、通信、依赖项和内部。正反馈导致的连锁故障是微服务应用中一种很常见的故障形式。大部分是连锁故障由服务过载所导致的。可以使用重试和超时时间的策略来减轻服务交互中出现的故障的影响。在采用重试方法时，开发者要加倍谨慎，以免加重其他服务的故障。可以使用缓存、候选服务和默认值等后备方案来返回成功的结果，即使服务依赖不可用。应该在服务交互中将超时时间传播到下游服务，这样不仅能够确保在整个系统内超时时间是一致的，还可以少做无用功。当错误量达到一定阈值时，服务之间的断路器会通过快速失败来避免连锁故障。服务可以使用限流策略来保护其免于受到突发的超过服务容量承载能力的负载请求高峰的影响。每个服务应该为负载均衡器和监控系统开放健康检查接口供其使用。可以通过压力测试和混沌测试来有效地验证系统可恢复性。可以采用一些标准一不管是通过框架还是代理一来帮助工程师快速开发出默认具有容错性的服务。
第7章构建可复用的微服务框架；
第8章微服务部署；
部署新的应用和变更必须标准化和简单明确，以免在微服务开发过程中出现摩擦。微服务可以运行在任何地方，但是理想的部署平台需要支持一系列功能，包括安全、配置管理、服务发现以及冗余。开发者将一个典型服务部署为一组完全相同的实例，并与一-个负载均衡器连接。实例组、负载均衡器以及健康检查能够让所部署的服务实现自愈和自动扩容。服务工件必须是不可变的和可预测的，以将风险控制到最小，降低认知难度，简化部署抽象。开发者可以将服务打包为特定于语言的包、操作系统软件包、虚拟机模板或者容器镜像。添加/删除微服务的单个实例是基本的初级操作，可供开发者组合成更高级别的部署。开发者可以使用金丝雀部署或蓝绿部署来降低意外缺陷对可用性的影响。
第9章基于容器和调度器的部署；
将微服务打包为不可变的、可执行的工件能够让开发者通过基本操作来对部署过程进行编排。为了方便服务开发和部署，调度器和容器会将底层的机器管理概念抽离出去。调度器的工作是设法将应用的资源需求与集群机器的资源使用情况匹配起来，同时对运行中的服务进行健康检查以确保它们正确运行。Kubernetes具备了微服务部署平台的理想特性，包括密码凭据管理、服务发现和水平扩容。Kubernetes用户定义了所期望的集群服务状态,而Kubermetes会不停地执行“观测-比较执行”这-循环操作来计算如何达到所期望的状态。Kubernetes的逻辑应用单元是pod:一个容器或者在一起执行的多个容器。复制集管理pod组的生命周期。如果现有的pod出现故障，复制集会启动新的pod。Kubernetes中的部署对象被设计用来通过对复制集中的pod执行滚动更新来保持服务可用性的。开发者可以使用服务对象来对底层的pod进行分组并供集群内外的其他应用访问。
第10章构建微服务交付流水线；
微服务部署过程应该满足两大目标:节奏安全和--致性。部署新服务所花费的时间通常是微服务应用中的一大阻碍。对微服务而言，持续交付是理想的部署实践方式，它通过快速交付小版本的经过验证的变更集来降低风险。良好的持续交付流水线能够确保部署过程的可见性、部署结果的正确性，并能够向工程师团队反馈丰富的信息。Jenkins是非常流行的自动化构建工具，它使用脚本语言将不同的工具联系到一.起并组合成交付流水线。预发布环境是非常有价值的，但是当面对大量的独立变更时,维护好预发布环境也面临着巨大的挑战。读者可以在各个服务上复用声明式流水线步骤;积极推动标准化能够提高不同团队间部署过程的可预测性。为了对发布和回滚提供细粒度的控制，读者应该将部署这一技术活动与功能发布的业务活动分开管理。
第11章构建监控系统；
第12章使用日志和链路追踪了解系统行为；
读者可以使用Elasticsearch、Kibana和Fluentd一起搭建一套日志基础设施,并使用Jaeger搭建一套分布式链路追踪系统。日志基础设施可以生成、转发和存储索引的日志数据以方便检索和关联不同请求。分布式链路追踪能够让开发者跟踪不同微服务之间的请求的执行过程。除了度量指标集合，链路追踪能够让开发者更好地了解系统的运行方式，发现潜在问题并随时对系统进行审查。
第13章微服务团队建设；
这份【微服务实战】文档共有551页，感兴趣的小伙伴请私我
文章为作者独立观点，不代表观点
相关文章
股民评论