《从0到1实战微服务架构》pdf电子书免费下载
下载方式一：
百度网盘下载地址：https://pan.baidu.com/s/1taiCUOYoR_71LBm5_MKdqw
百度网盘密码：1111
下载方式二：
http://ziliaoshare.cn/Download/af_124447_pd_C0D1SZWFWJG.zip
|
|
作者：empty 页数：323 出版社：empty |
《从0到1实战微服务架构》介绍
微服务是继SO A后， 最流行的服务架构风格之一， 按照微服务对系统进行拆分后，每个服务的业务逻辑都更加简单、清晰。服务之间是松耦合的，模块之间的边界也更加清晰。微服务有效降低了软件项目的业务复杂程度.
微服务是继SO A后， 最流行的服务架构风格之一。按照微服务对系统进行拆分后，每个服务的业务逻辑都更加简单、清晰。服务之间是松耦合的，模块之间的边界也更加清晰。微服务有效降低了软件项目的业务复杂程度，为小团队独立开发、持续交付和部署打下了良好的基础。遗憾的是，微服务并不是银弹。与传统的单一架构相比，微服务架构对团队的组织架构、技术水平、运维能力等方面，都提出了更高的要求。如果没有掌握得当的方法而生搬硬套，微服务架构只会会适得其反―一降低项目的开发效率，这是本书的创作初衷之一。在国内外的技术社区中， 比较推崇现有开源方案， 如 Spring Cloud全家桶 或者阿里开源的 Dubbo 。上述框架通常已经实现了服务发现、配置、负载均衡、限流熔断， 等微服务架构所必须的的核心功能。使用开源框架省却了造轮子的过程，但也降低了我们学习、思考的欲望。为什么需要服务发现，又如何实现它呢?配置中心呢.思考和设计的过程充满了挑战，也是提升自身架构能力的一种手段。这是本书的创作初衷之二已有的微服务资料过于重视微服务的开发，忽略了微服务赖以生存的生态系统：工具链、自动化运维。可以说，离开了这两点的支持，微服务架构将难以落地。完善这两方面的思考和实战，是本书的创作初衷之三。为此，我撰写了这本《从0到1实战微服务架构》。让我们 暂时忘掉”已有的、成熟的开源解决方案。尝试亲自动手，实现微服务架构的各个模块。我们会从微服务开发、工具链、运维这三个角度，阐述微服务架构的实战方案如果本书帮助了你， 欢迎在在git hub加Star， 但严禁用于商业用途!(参见本页底部版权声明)由于能力水平所限， 本书难免存在各种错误， 恳请各位进行指正(Issue or PR) ， 谢谢!读者基础由于篇幅、精力所限，本书无法写成一本 零起点 教程。我假设读者具有至少2年的服务端工作经验，并且了解以下技术或原理：
本书可以供架构师、项目经理、高级服务端程序员参考、学习。动手实战是本书的核心内容， 因此本书所涉及的全部代码， 都托管到了我的Git hub上(以lms i a-开头的项目)。这些代码以研讨为主要目的，也可以直接应用于生产，但本人不对其稳定性负责。在线阅读地址
当我们谈微服务架构时，我们需要关注哪些点，本章将从这里说起。在了解了微服务的整体架构后，我们会从 研发工具链”、“微服务技术栈”、“运维技术链条”三个角度展开。我们会讨论微服务架构中，如何对这三类问题进行技术选型以及做出这些选型决策的原因。同时，我们将探讨如何将这三部分有机地融入到微服务架构中。
微服务架构概览在正式讨论微服务架构前，有必要用简短的篇幅，讨论下微服务以及这种架构风格的优点和缺点。在微服务出现之前，我们的架构多数是单体应用架构。会有一个或者少数几个”巨无霸“进程，里面可能包含了 用户管理、”订单管理“、“支付确认“、“物流 等等各种复杂的业务逻辑和功能。这种传统的单块应用架构风格是很直观、自然的，然而在现代软件开发领域，特别是互联网开发领域中，单块架构遇到了一些问题。
单块架构的缺点·耦合严重：单块服务内的各个逻辑之间，往往缺乏清晰的边界。导致内部耦合严重，正所谓“牵一·维护困难：单快服务包含了过多的业务，代码量严重膨胀。开发人员难免 失焦“，不知道如何下·团队协作困难：如果多人同时开发同一个单块应用，势必导致代码冲突成为常态，团队协作成本·测试困难：单块服务是作为一个整体进行开发、上线的。尽管你只对A功能进行了修改，但难免上述单块应用的缺点，在传统软件开发中，尚可通过“小心规划”、“人海战术 等方法解决。但到了互联网时代，就很难实现了，为什么这么讲呢?互联网软件开发，讲究的是“快糙猛 ，对迭代速度的要求非常高。对于成熟的互联网企业，一个项目在一天内上线好几次，都是稀松平常的事情。试想一下我们的单块“巨无霸“服务，稍微改动一点，就要经过复杂的代码评审、测试验证，如何才能跟上快节奏的迭代和上线呢?尽管微服务不是银弹，但微服务的出现，确实从一定程度上改善了这种情况。微服务是一种架构风格，将单块应用划分成一组小的服务，服务之间相互协作，以组合的形式，实现复杂的业务功能。微服务架构的优点·低耦合：在单块服务中，不同业务的逻辑耦合在一起。做微服务拆分后，微服务内只包含有限的·易维护：微服务内部只包含单一业务逻辑，功能更为集中，更容易开发人员聚焦问题和修改。·适合团队协作：拆分为微服务后，每个服务中涉及的代码和功能更少，可以将不同微服务划分给发而动全身”。手。
急剧上升。会影响B功能。随着单块应用的愈发膨胀，测试工作量会提升数倍。业务逻辑，耦合也随之大大降低不同团队甚至个人负责。各司其职后，有效降低了开发和代码冲突，使得其适合团队协作。·测试成本低：在单块服务中，哪怕只改动了一点点代码，也需要对整个巨无霸服务进行测试。微服务拆分后，功能的修改，只需要涉及改动的个别微服务进行测试，有效降低了测试工作量。·易横向拓展：在单块服务时代，巨无霸服务已经占用了大量资源，机器的配置已经很高，若要再单独部署一个结点做负载均衡，成本会非常很高，所以多数情况下，都是通过纵向拓展的方式提升系统性能(如加内存， 换个更好的cpu) 。采用微服务拆分后， 各个微服务占用的资源更少， 可
以轻松的通过增加节点的横向拓展方式，提升系统性能。更进一步的说，根据阿姆达尔定律，微服务拆分后，各个微服务对性能的要求并不一致，可以优先拓展那些具有性能短板的微服务，有效降低了拓展成本。·技术选择更多样：由于微服务是各自独立的进程。各个团队可以根据自己的需要选择不同的技术方案。然而在实践中，我并不推荐这么搞，这会在后面技术选型时展开。·加快迭代速度：上面已经提到，微服务低耦合、易维护、适合团队协作、测试起来成本更低，也更易于横向拓展。采用微服务架构后，可以显著的提升迭代速度。尽管微服务具有这些优点，我想再次强调： 微服务不是银弹“ ，他解决了单一服务的软件复杂度，提升了迭代速度，但也带来了一些缺点。微服务架构的缺点·运维难度加大：在单块架构中，不管改动多少需求，只需要上线一个服务。而采用微服务后，为·开发能力要求高：在单块架构中，巨无霸服务的逻辑都在一个项目中。采用微服务后，逻辑分散·调试难度更大：在单块架构中，我们只需要关注一个或少数几个服务。应用微服务架构后，后端幸运的是，通过容器等的新技术的引入，以及合理的架构设计，这些缺点都可以得到一定程度的缓解。本书会在后续章节对这些问题进行展开。在讨论了微服务的优缺点之后，我们可以看一下微服务的整体架构了。了一个需求，可能要上线一堆服务。在不同的项目中，在加上微服务架构本身引入的新技术，对开发能力提出了更高挑战系统演变为分布式系统，可能会出现A调用B，B调用C，甚至C还要调用D的长调用链，势必增加了调试和问题排查的难度接入网关层接入网关服务1接入网关服务2接入网关服务3接入网关服务4业务服务层业务微服务1业务微服务2业务微服务3业务微服务4微服务设施注册与发现容错与限流配置平台日志、监控、报警后端组件运维平台持续部署系统部署版本管理系统容器资源监控、调度、管理系统基础设施计算资源存储资源网络资源机房或云平台维护如上图所示，微服务架构可以大致分为五个层次，我们自底向上，逐层做一下解释。。基础设施层·运维平台层·微服务设施层本文档使用书栈网-BookStack.CN构建-10-微服务整体架构。
微服务是后端服务，最终一定要部署在基础设施的某台机器上。基础设施层可以是自运维的服务器或机架，也可以选用云计算的虚拟机。。在这一层， 我们重点关注底层 物理资源 ^1的可用性及调整：计算资源(CPU和GPU) 、存储资源(内存、硬盘)、网络资源(交换机、路由)。对这些基础设施的维护，或者是直接在机房维护， 或者是操作云平台的API。。举几个例子：大促前预估系统容量不足，我们要加半个机架的机器；直播平台今晚要来大V，预计带宽不足，要增加带宽。这些都是在基础设施层要关注的内容。。对于后端服务的运维工作，持续交付是最重要的能力。由于微服务数量众多，一般需要构建一个持续交付系统，来完成微服务的自动运维，如微服务的初始化、发布、回滚、扩容。。采用微服务架构后，上线的次数、频率都会显著提升，这就需要一个上线的镜像版本管理系统，记录上线的镜像版本。在微服务架构中，一般采用容器技术来实现微服务的自动运维。。容器是轻量级资源，隔离能力相对较弱，我们需要对容器资源进行监控，调度和管理。举个例子：我们有三台物理机，现在物理机A和C各运行了20个容器，物理机B运行了22个容器，假设每个容器的资源占用完全一致，那么资源调度系统会自动地，将B的两个的容器调整到物理机A和C上。
。假设服务A需要调用服务B，那么A服务如何获取服务B的地址(例如IP和端)呢?在传统的单块架构中，服务数量很少，尚可采用同在配置中写死IP、端的方法来解决这个问题。但在微服务时代，面对动辄成百上千的微服务，这种做法将不再可行。因此，如何自动注册、发现微服务的多个实例，是架构必须解决的核心问题。。微服务拆分后，我们的系统从单机演化为分布式系统，为了防止分布式系统的雪崩效应^2、微服务设施需要有的熔断和限流的能力。。面对众多的微服务，逐一修改配置的方式显得更加笨拙，我们需要有一个中央配置平台，快速完成微服务的配置修改。前面已经提到，微服务的分布式架构，会加大调试难度，所以日志的收集和预警显得更加重要，同时，我们可以根据业务日志来进行一些监控预警，这和平台层的容器监控预警是不一样的。。微服务需要集成一些后端组件，如数据库、消息队列、缓存等。·运维成本更低，想对机器加64GB的内存，如果自运维的话跑去机房、断电、拆机器、插内存，半天过去了。如果采用云主机，就是点点鼠标，重启一下的事情。。弹性更大。老板一拍脑袋，明天要上线大促，预估要扩容10倍。只有一天时间，是不可能完成100台机器的采购、上架、配置的。大促结束后，流量回归到平常情况，这100台机器还要继续空转烧钱么?如果采用云主机， 这些就是点点鼠标， 甚至是几个API调用就可以搞定的事情。。平均稳定性更高。内存ECC故障、硬盘坏道、RAID卡故障， 这些都是自运维服务器时代的家常便饭。若采用云主机，就可以很好的避免这些烦恼。常见的大厂云主机，都提供了至少3个9的在线时间保障，与运维服务器相比，平均稳定性更高。方案有：docker加脚本、swarm集群、Ku bernet es集群、Marathon集群。本书选用Ku bernet es集群， 它内置的功能完全可以满足 容器的监控、调度、管理“。在这里我们采用排除法，说说为什么不选用其他几个方案。。docker加脚本：2014年Docker刚刚兴起时， 还没有集群管理的解决方案， 多数公司采用·业务服务层：在提供了微服务的基础设施后，我们可以放手开发各个微服务了。业务服务层是一些“基础微服务”或“业务微服务”，他们“各司其职 ，服务之间的耦合应当做到最低。·接入网关层：微服务面向的 用户 ， 一般是Web、移动端、PC端等。出于用户体验的考量， 服务端提供给客户端的的接应当尽量实现结果聚合，减少请求次数。因此，一般要设置一层接入网关， 他负责调用业务微服务ABC等， 完成结果聚合后， 一并返回给客户端。在绝大多数的公司中，业务规模不会很大，所需要的机器也非常有限，基础设施层往往会使用云平台或机房托管的外包方式完成。因此，本书将不对基础设施层做过多讨论
运维工具链概览在看过微服务整体架构后，我们来讨论下架构的各个层次中，本书所选用的技术栈。与前面类似，我们依然自底向上讨论。运维工具链选型·基础设施层：对于绝大多数的中小公司，且无强烈的数据保密需求，我强烈建议使用云主机。·运维平台层之容器管理：前面已经提到，微服务需要借助容器技术才能 顺利启航 。目前主流的了这类架构，在不同物理机器上，通过自动化脚本来启动不同的容器。这种方式简单直接，但是当集群规模扩大后，运维非常困难。此外，这种方式很难解决自动网络配置、自动调度、容器数据迁移等很现实的问题。swarm集群：swarm集群方案是Docker公司于2014年末推出的容器集群技术方案。尽管swarm是Docker公司的“亲儿子 又是市场的先发产品， 但swarm很快被后起之秀Ku bernet es超越， 时至今日， 从的新功能跟进、社区活跃、文档完善程度等方面， 都弱于Ku bernet es。更重要的是， 借助CNC F基金会的影响力， Ku bernet es已经成为了事实上的容器集群解决方案， GCE、AWS等云平台， 都原生支持Ku bernet es集群。在2017年，Docker公司在自己的商业化产品中直接集成了Ku bernet es， 标志着swarm项目的全面落败。所以在本书中， 我们也不会选用swarm集群。。Marathon集群：Marathon是构建在Mesos集群上的一套容器集群管理软件。想使用Marathon， 先要部署一套底层的Mesos。对于大型公司， 特别是已经部署了Mesos的Had oop集群的公司来说， 这种搞法可以提升机器复用程度。但对于中小规模的企业而言，Mesos+Marathon多少有一些“ 高射炮打蚊子“的感觉。此外， 虽然Marathon在大规模机器管理上有比较多的经验，但并未在容器编排上投入太多新功能，更像是借助容器的概念为自己 造势”。综上所述， 我们也不会选用Marathon集群。
运维平台之持续部署系统：部署前需要先构建， 本书的微服务开发选用Spring Boot框架， 在构建方面， 我们使用Grad le(之后会阐述原因) 。在持续部署方面， 我们选用老牌工具Jenkins，通过一些插件和配置完成全套的持续部署。·运维平台之部署版本管理系统：前面已经提到， 我们将采用容器技术。本书采用自建私有Docker仓库的方式，完成容器的镜像工作，并使用它作为部署版本的管理系统。本书的主线是微服务的架构及开发。为了保证这一主题的的稳定和连惯性，我们将上述运维工具链的使用单独抽提出来，在《运维工具链》一章中介绍上述内容。本文档使用书栈网·BookStack.CN构建-13微服务技术栈概览
下面来看一下微服务相关的技术选型·服务开发框架：在微服务开发方面， 我们选用Java作为开发语言。市面上的语言众多， 特别近几年来， Go、Rust语言作为服务端语言快速崛起。既然如此， 我们为什么还要选用基于Java语言呢?尽管Go等语言崛起的很快，但相对依然小众，能够熟练运用这些语言进行生产开发的人才更是少之又少，从人才供给量上就无法满足业务需求。此外，新兴语言的社区相对活跃，版本变化较为频繁， 经常出现各种不兼容升级， 各种坑， 这些都不利于业务的开发。反观Java， 虽然大家都批评多年来一直是“八股文 ， 但一直保持向下兼容， 且依然稳重求进。最终要的是， Java拥有 海量 的开发人员基础， 人才供给不会成为瓶颈。因此， 我们选用Java作为开发语言， 并使用Spring Boot作为开发框架。Spring Boot作为Spring框架的一次“革命”， 可以说是为了微服务而生的， 在本书的后续章节， 大家会逐渐体会到选用Spring Boot的原因，·服务注册与发现：为了简化实现难度， 我们将借助Ku bernet es内置的服务和虚拟端功能， 来实现服务的注册与发现。换句话说，我们将服务注册与发现的能力，下推一层到运维平台层。对于微服务这一层，服务的注册与发现是完全透明的。·熔断与限流：微服务之间的调用链更加复杂，为了降低&隔离服务故障造成的影响，一般选用和熔断或限流策略。我们选用Hystrix作为熔断功能的基础库并进行了封装， Guava的Rate Limit作为限流功能的基础库并进行了封装。·配置中心：这里主要关注配置的自动下发、自动更新和易维护性。我们采用git+cfg4j的模式实现配置中心。