本书不会重复造轮子,写出差异化,以实用性为初心,实例化引导为手段,避免阳春白雪式的理论宣导,或是皮相之谈的代码解读。总结而言本书的特点如下:
实例导向,理论为辅:笔者多年服务于互联网金融公司,本书以信贷系统这一真实项目为线索,循序渐进地介绍服务架构的来龙去脉,微服务架构的基础性理念介绍是必须的,但不会生搬硬套地解释某些知识点的设计原理,而会更加关注在架构演进过程中为什么要用到这些技术及这些技术的适用场景及局限。
言简意赅,拒绝话痨:对比国内外技术书箱,很大的差异在于国内很多作者喜欢“堆代码”,喜欢“旁征博引”,本书不求“厚”,但求“精”,对于一些显而易见或是网络中已有详尽介绍的知识点本书尽量以扩展阅读的形式呈现给读者,不占用过多篇幅介绍。
内容殷实,力求全面:在保证行文紧凑的同时,本书尽量覆盖服务架构的核心点、项目实例的全流程关键点,并且会引入一些相关的扩展话题以供探讨,IT技术的发展可能是各个行业中最快的,服务架构做为最重要的IT基础性技术之一自然也在快速地进化,所以本书也会用适当的篇幅用实例介绍目前比较业界被看好的Service Mesh及Serverless技术。
扩展丰富,追根溯源:本书以脚注或扩展阅读的形式引用了大量基础或发散性的解释说明做为知识体系的补充,引文力求正本清源,多为论文链接或权威网站(多见于Wikipedia、InfoQ、IBM)的一手资料。
实例导向,理论为辅:笔者多年服务于互联网金融公司,本书以信贷系统这一真实项目为线索,循序渐进地介绍服务架构的来龙去脉,微服务架构的基础性理念介绍是必须的,但不会生搬硬套地解释某些知识点的设计原理,而会更加关注在架构演进过程中为什么要用到这些技术及这些技术的适用场景及局限。
言简意赅,拒绝话痨:对比国内外技术书箱,很大的差异在于国内很多作者喜欢“堆代码”,喜欢“旁征博引”,本书不求“厚”,但求“精”,对于一些显而易见或是网络中已有详尽介绍的知识点本书尽量以扩展阅读的形式呈现给读者,不占用过多篇幅介绍。
内容殷实,力求全面:在保证行文紧凑的同时,本书尽量覆盖服务架构的核心点、项目实例的全流程关键点,并且会引入一些相关的扩展话题以供探讨,IT技术的发展可能是各个行业中最快的,服务架构做为最重要的IT基础性技术之一自然也在快速地进化,所以本书也会用适当的篇幅用实例介绍目前比较业界被看好的Service Mesh及Serverless技术。
扩展丰富,追根溯源:本书以脚注或扩展阅读的形式引用了大量基础或发散性的解释说明做为知识体系的补充,引文力求正本清源,多为论文链接或权威网站(多见于Wikipedia、InfoQ、IBM)的一手资料。
2021年10月30日 我们谈了很多微服务改造的点,但已有项目转微服务势必会遇到一个棘手的问题:新系统怎么替换老系统?下面我就讨论下几种主流方案。
2021年10月30日 微服务的特点决定了它会存在较长的调用链路,一个请求一般会跨3个以上的服务(网关->应用聚合层->服务化层)而跟踪它的调用情况是异常定位及性能优化的关键之一。要能跟踪我们势必需要在日志中记录每个请求唯一的跟踪Id,我们可以在HTTP请求或MQ接收时判断消息Header是否存在Trace_Id,如果不存在则认为是新的请求,进而生成一个UUID作为Trace_Id,如果存在则沿用这个Trace_Id,然后在打日志时加上这个Trace_Id。最后通过日志收集工具将这个本地日志收集到一个聚合平台上进行查询。这能解决问题,实际上这也是Google Dapper(《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》)的核心思路,Google Dapper是Google的日志追踪服务。
2021年10月30日 容器化部署是微服务非常理想的选择,它可以实现上文提到的快速发布及本节要谈的自动化节点伸缩与故障转移。
2021年10月30日 服务监控是保证生产环境稳定最基础也是最重要的措施,微服务下尤是。如果没有成熟的一套监控方案那微服务化注定会失败!
2021年10月30日 传统的服务运维对自动化的要求不需要太高,但使用微服务后服务的数量会急剧上升,一个成熟的微服务可能有几十到几百个组件,每个组件做HA,最终可能有成百上千个实例,同时还要考虑开发、测试、UAT/预发、生产、灰度等环境,人工部署将是灾难性的。
2021年10月30日 测试是保障软件质量的关键,对一个成熟稳定的产品而言开发的质量未必一定很高,但绝对是非常注重测试以把守好发布上线的最后一关。
2021年10月30日 单元测试的重要性不言而喻,这是所有测试的第一道关,是所有测试的基础。在微服务下会有很多个服务,对各服务组件自身的测试也会很重要,组件测试会覆盖当前服务的所有对外接口实现对各个服务的功能边界验证。单元测试和组件测试可以很好地发现各单点或各服务的问题,但它无法检查系统的流程行为,而这就需要集成测试来验证组件之间的通信路径和交互,集成测试关注的一次请求或一个业务流程是否正常,集成测试多针对接口,某些情况下我们可能会特别关注用户交互,而UI测试(或End-To-End测试)可以比较好发现这类问题。
2021年10月30日 接口(API)是服务能力的包装及体现,是服务提供的直接途径,也是做为服务使用方最关注的方面,一个设计合理、稳定不易变、文档清晰的接口集合是服务质量重要组成。
2021年10月30日 上文讲的是人员和团队,提出要将团队划小管理,那具体到开发层面,我们如何建立与之对应的工程结构及版本管控呢?
2021年10月30日 在传统的SOA架构中我们以系统为边界进行划分,通过标准的协议实现系统间交互,在这一体系架构下成员归属于某个具体系统,工作任务即为所属系统的需求,所对应的组织结构会相对稳定、清晰,而微服务架构以服务的粒度进行划分,要求打破系统边界实现更小粒度的服务级重用,这带来的结果是随着业务的增长技术架构的重心会越来越下沉到公共服务层,逐渐形成我们现在常说的大中台小前台体系,可以让前台业务项目做得很“薄”,这时我们发现开发一个项目原本拉一个新的业务开发团队就可以独立完成,但现在有很多公共的服务可以重用,新的业务开发团队人员会减少、项目的工期会缩短,但与之而来是需要有大量跨团队的沟通协调、开发测试工作,这就与我们之前的团队管理有比较大的区别。上面的情况会出现在服务化相对成熟的公司,对于刚开始做微服务化的公司而言没有那么多可以重用的服务,如何通过一个个项目的迭代实现从0到1的服务化建设,如何在一个中大型项目中设计符合微服务体系的团队架构成了项目成败的关键之一,这是每个项目负责人在立项时不得不考虑的问题。
2021年10月30日 上文我们讨论过ACID、基于2PC、TCC等方案的分布式事务、FLP Impossibility、拜占庭与非拜占庭下的领导者选择及其Paxos、Raft等实现算法,而这之中最核心的问题在于调和分布式环境的数据一致性与服务可用性。对此在2002年来自MIT的Seth Gilbert 和Nancy Lynch教授在《Brewer's conjecture and the feasibility of consistent, available, partition-tolerant web services》论文中证明了Eric Brewer于早前提出的猜想并正式确立了CAP理论。于今天而言在众多的分布式系统架构基础理论中CAP可能为人所知,本节我们花些篇通俗地介绍下CAP及其相关概念。
2021年10月30日 有某些场景下我们希望一些任务只在一个实例执行,最常用的可以考虑用MQ实现,但例如定时任务,到时间后执行一个任务,同一时间任务只能执行一次,在没有分布式调度服务的前提下我们更倾向于用一个特定的节点执行,但如何确定这个节点呢?显然我们不能只部署一个实例,这违反了高可用性要求,再考虑实例可能会宕机所以我们其实需要有一个机制可以动态找到一个特殊节点用于执行特定工作,并且在这一节点宕机后可以快速重新指定新的特殊节点,而这就是领导者选举所应对的一个典型场景。
2021年10月30日 上节介绍了顺序处理,我们实际场景中还会遇到诸如这些情况,比如对页面操作记录时要求操作事件是顺序的:Beforeload必须先于Unload,事件由同一个终端设备发送,通过设备ID Hash到同一个节点服务处理,这之中不存在时钟一致性问题,但由于事件发送是异步的,所以接收可能乱序,再比如在大数据系统中分析OAuth关系,OAuth表记录的是A应用的X用户与B应用的Y用户的关联(如果B应用没有对应的用户则Y用户为新增记录),但用户表、应用表和OAuth表都是分开采集的,即不能保证分析OAuth表时用户表对应的用户就一定已经存在。对于这类需求比较通用的解决方案是使用延迟队列。
2021年10月30日 绝大多数的场景下,我们的业务操作不需要保证严格的顺序处理,但在数据存储上却是最常规的要求。比如MySQL在集群模式下多节点间的数据写入顺序必然是需要一致的。在业务操作上比较典型的是数据库日志(MySQL的Biglog或Mongo的OptLog等)的同步,我们一般会订阅到Kafka,然后从Kafka异步消费,这之中就要保证消费时记录的顺序与数据库一致。
2021年10月30日 Id(Identification)是我们熟知的概念,用于标注对象身份,比如表主键、订单号、交易流水号、业务编码等,这些字段要确保全局唯一,在分布式环境下视场景的不同可以从极为简单到非常复杂,以订单号为例,不同的系统下订单号需求可能是随机的,可能是要求有顺序的,为了避免被竞争对手分析也可能要求是顺序与随机组合的(比如高位为日期,低位为随机数),不同的系统规模实现的手段可能是完全不同的,一些大型平台的Id生成服务会由成百上千个节点组成。总的来看全局Id策略的实现常见于以下几种:
微服务是继SOA后,最流行的服务架构风格之一。
按照微服务对系统进行拆分后,每个服务的业务逻辑都更加简单、清晰。服务之间是松耦合的,模块之间的边界也更加清晰。
微服务有效降低了软件项目的业务复杂程度,为小团队独立开发、持续交付和部署打下了良好的基础。
遗憾的是,微服务并不是银弹。与传统的单一架构相比,微服务架构对团队的组织架构、技术水平、运维能力等方面,都提出了更高的要求。如果没有掌握得当的方法而生搬硬套,微服务架构只会会适得其反--降低项目的开发效率,这是本书的创作初衷之一。
在国内外的技术社区中,比较推崇现有开源方案,如"Spring Cloud全家桶"或者阿里开源的"Dubbo"。上述框架通常已经实现了服务发现、配置、负载均衡、限流熔断,等微服务架构所必须的的核心功能。
使用开源框架省却了造轮子的过程,但也降低了我们学习、思考的欲望。
为什么需要服务发现,又如何实现它呢?配置中心呢....思考和设计的过程充满了挑战,也是提升自身架构能力的一种手段。这是本书的创作初衷之二。
已有的微服务资料过于重视微服务的开发,忽略了微服务赖以生存的生态系统:工具链、自动化运维。可以说,离开了这两点的支持,微服务架构将难以落地。完善这两方面的思考和实战,是本书的创作初衷之三。
为此,我撰写了这本《从0到1实战微服务架构》。让我们"暂时忘掉"已有的、成熟的开源解决方案。尝试亲自动手,实现微服务架构的各个模块。
我们会从微服务开发、工具链、运维这三个角度,阐述微服务架构的实战方案。
由于篇幅、精力所限,本书无法写成一本”零起点”教程。我假设读者具有至少2年的服务端工作经验,并且了解以下技术或原理:
Git
Maven & Gradle
Docker & k8s
Java
Spring / Spring Boot
数据库: 如MySQL
消息队列: 如RabbitMQ
缓存系统: 如Memcached
内存数据库: 如Redis
本书可以供架构师、项目经理、高级服务端程序员参考、学习。
动手实战是本书的核心内容,因此本书所涉及的全部代码,都托管到了我的Github上(以lmsia-开头的项目)。
这些代码以研讨为主要目的,也可以直接应用于生产,但本人不对其稳定性负责。
按照微服务对系统进行拆分后,每个服务的业务逻辑都更加简单、清晰。服务之间是松耦合的,模块之间的边界也更加清晰。
微服务有效降低了软件项目的业务复杂程度,为小团队独立开发、持续交付和部署打下了良好的基础。
遗憾的是,微服务并不是银弹。与传统的单一架构相比,微服务架构对团队的组织架构、技术水平、运维能力等方面,都提出了更高的要求。如果没有掌握得当的方法而生搬硬套,微服务架构只会会适得其反--降低项目的开发效率,这是本书的创作初衷之一。
在国内外的技术社区中,比较推崇现有开源方案,如"Spring Cloud全家桶"或者阿里开源的"Dubbo"。上述框架通常已经实现了服务发现、配置、负载均衡、限流熔断,等微服务架构所必须的的核心功能。
使用开源框架省却了造轮子的过程,但也降低了我们学习、思考的欲望。
为什么需要服务发现,又如何实现它呢?配置中心呢....思考和设计的过程充满了挑战,也是提升自身架构能力的一种手段。这是本书的创作初衷之二。
已有的微服务资料过于重视微服务的开发,忽略了微服务赖以生存的生态系统:工具链、自动化运维。可以说,离开了这两点的支持,微服务架构将难以落地。完善这两方面的思考和实战,是本书的创作初衷之三。
为此,我撰写了这本《从0到1实战微服务架构》。让我们"暂时忘掉"已有的、成熟的开源解决方案。尝试亲自动手,实现微服务架构的各个模块。
我们会从微服务开发、工具链、运维这三个角度,阐述微服务架构的实战方案。
由于篇幅、精力所限,本书无法写成一本”零起点”教程。我假设读者具有至少2年的服务端工作经验,并且了解以下技术或原理:
Git
Maven & Gradle
Docker & k8s
Java
Spring / Spring Boot
数据库: 如MySQL
消息队列: 如RabbitMQ
缓存系统: 如Memcached
内存数据库: 如Redis
本书可以供架构师、项目经理、高级服务端程序员参考、学习。
动手实战是本书的核心内容,因此本书所涉及的全部代码,都托管到了我的Github上(以lmsia-开头的项目)。
这些代码以研讨为主要目的,也可以直接应用于生产,但本人不对其稳定性负责。
2021年11月02日 子曰:“工欲善其事,必先利其器”。前面已经提到,微服务架构的对开发水平提出了更高的=要求,我们更应该注重研发工具链的建设,以提高开发效率。
2021年11月02日 下面来看一下微服务相关的技术选型
2021年11月02日 在看过微服务整体架构后,我们来讨论下架构的各个层次中,本书所选用的技术栈。与前面类似,我们依然自底向上讨论。
2021年11月02日 在正式讨论微服务架构前,有必要用简短的篇幅,讨论下微服务以及这种架构风格的优点和缺点。