代码编织梦想

微服务相关的书籍多如牛毛,在众多书籍中找出适合自己看的的确不易,这里推荐两本自己看过的,并整理了自己的读书笔记分享给大家。

《微服务设计》

微服务笔记:百万程序员都读过的两本书!_第1张图片

作者:[美] Sam Newman

这本书只有200页,但是麻雀虽小五脏俱全,完整介绍了微服务设计所涉及的各个方面。包括微服务的优点,微服务如何拆分,大规模微服务化的主机管理、服务部署、服务测试、服务安全、服务监控、服务治理以及康威定律。

  • 服务拆分:微服务的拆分需要熟悉业务领域,常见的理论支撑是DDD,对于不熟悉的领域,作者不推荐太着急去服务化,而是保持单块系统,随着对领域的熟悉逐步拆分。而对于领域边界十分清晰的场景就可以进行细粒度拆分,进行大规模的服务化。保持服务的自治性和独立部署性是基本原则。
  • 服务管理:大规模服务化之后,自然带来服务的如何管理的问题,是物理机、虚拟机、还是容器化部署。显然容器化是未来的趋势,因为容器资源占用更轻量级,启动速度更快,适合服务的弹性伸缩。
  • 服务监控:服务规模增大,复杂性急速增长,企业中服务可能成千上万,出错的概率也增大了,如何在出问题时快速定位边界,就需要对服务调用链进行跟踪,对服务调用指标进行采集,最好是以可视化图表方式展示出来。
  • 服务管控:服务调用链路需要在流量超过承载能力后,有容错措施,比如对上游服务限流、对下游服务调用进行熔断、下游出问题时上游直接降级等等。
  • 服务测试:对于软件开发工作来讲,测试的重要性不言而喻。测试包括单元测试、服务测试、端到端测试粒度有低到高三个层次。单元测试可以通过持续集成CI能力融合进去,每次提交代码后都自动一遍单测,可以快速反馈开发问题。
    当然还有一些其他的内容,比如服务之间调用时同步还是异步,是采用rpc还是rest协议。以及康威定律讲到的组织与软件架构之间的关系,以及微服务架构下的安全如何去应对。还是推荐可以看一看,对微服务设计需要考虑的点有一个总体把握。

《微服务治理:体系、架构及实践》

微服务笔记:百万程序员都读过的两本书!_第2张图片

作者:李鑫
看完这本书最大的感受是两个字—度量,有点像是度量驱动开发的味道。

  • 度量驱动开发:告诉了微服务度量的核心指标有哪些,以及如何去度量这些指标的手段。比如对服务调用次数做汇总,而汇总又可以分为分钟级、小时级别。

  • 微服务架构鲁棒性:然后,还写了关于微服务架构鲁棒性(或健壮性)的架构保障,指出业界鲁棒性的设计原则:冗余、弹性伸缩、单点无状态、不可变基础设施、故障传导阻断(比如熔断、限流、降级、超时、幂等等策略)、基础设施即代码等。其中,"单点无状态"是弹性伸缩的前提条件。而"基础设施即代码"也是快速部署、弹性伸缩的前提条件。**“基础设施即代码”**提供了一个虚拟层,屏蔽了底层资源比如服务器、网络、配置、DNS、CDN、防火墙、日志、监控等资源或者服务对于用户的差异。并将其抽象为一个虚拟世界的对象,通过编程的方式可以对这些对象进行编排和整合、调度。**用户通过这个虚拟层可以将大规模的部署指令化、程序化!**这样以来,基础设施才能快速响应快速迭代的产品需求,研发团队更高效的持续交付、devops才成为可能!

  • 集群容错:集群的容错机制有很多如failsafe提供的“调用永远正确”的机制,即当出现调用异常时返回一个新构建的结果。还有FailOver失败转移机制、Failback失败重试机制,此模式以固定的时间间隔重新发起远程调用。这里需要注意集群容错和容错降级的区别:集群容错是用于保证远程调用的可靠性,而容错降级是为了保障业务的可用性

  • 服务线上生命周期管理:比如服务的优雅停机、蓝绿发布、灰度发布、金丝雀测试这些概念。
    蓝绿发布的意思是调整路由及负载均衡策略,将流量统一切换到新版本(绿集群),但旧服务(蓝集群)不下线。此时两套集群并存,只是旧集群没有流量,一旦新版本服务出现异常,通过调整路由及负载均衡策略,快速切换回旧版本(蓝集群)。
    灰度发布其实是将流量分批次平滑发布,逐渐扩大范围,同时将选定的线上流量路由到新版本上,实时收集反馈验证发布效果,以决定是继续发布还是回滚。
    ☆那么什么是金丝雀测试呢?套用书中的原话:“在灰度发布中,第一批(或前N批)发布的服务节点及被切流到该节点上的用户流量具有特殊意义,它们往往扮演了“先行者”的角色,大部分异常都能在第一批发布中被发现。由于第一批(前N批)发布的范围非常小(一般不超过1%),影响范围有限,因此又把第一批(前N批)发布单独称为“金丝雀测试”。”

  • 服务线上稳定性保障
    ☆ 梳理线上故障场景,根据发生概率排序并制定预案。
    ☆ 预案的效率优先级排序,比如应对大流量场景是扩容,还是限流,各有什么优劣?
    ☆故障演练,保证出问题时候不手忙脚乱!
    ☆故障复盘,建议全员参与,避免公开指责某个人或团队。
    此外,还提到了混沌工程,它的本质是制造故障和脆弱点并改进。

  • 架构治理:主要涉及服务分层如何演进,比如通用业务层拆分出来形成业务服务层**,个性化功能中与业务无关的部分可以拆分出来,比如协议适配、拆包、安全校验等拆出来跟网关层合并为 安全网关层,然后就是对业务服务层及通用服务层功能的组装和聚合的“聚合服务层”。
    微服务笔记:百万程序员都读过的两本书!_第3张图片
    每个服务分层涉及的业务域各不相同,分工也不同。
    ⭐️
    通用服务层跨多个业务域,面向整个企业的业务提供共性的服务,比如在基金行业,通用服务层同时给直销、代销、高端理财这些不同的业务域提供通用服务。
    ⭐️
    业务服务层的范围则被控制在单个业务域之中,比如直销业务域会根据业务特色形成独有的业务服务层。不同业务域的业务服务层之间不存在复用关系,如果某个业务域下的服务能够被其他业务域复用,就应该把它继续下沉到通用服务层。
    ⭐️
    聚合服务层**更多和渠道关联,它承载的业务逻辑很少,主要起到对业务服务层和通用服务层的服务进行聚合和组装的作用。
    因此,聚合服务层、业务服务层、通用服务层三层服务分层的定义换个说法就是:业务前台服务层、业务中台服务层和通用后台服务层
    在服务分层架构下,各层的服务并不是静止不动的,通用服务会被不断下沉。所以越底层的服务抽象度越高,也越通用、越静态,不会经常改变;越靠近前端的服务越贴近业务,越不稳定,会随着业务的快速变化而不断改变,客观上也必须保持更“轻”的体态。
    可以将前台服务拆分得更细,让前台服务不用通过大量的代码来处理业务逻辑,只需要少量的黏合剂代码来对中台专属业务领域的通用服务和后台跨业务领域的通用服务进行快速组装和聚合,从根本上降低了前台服务开发的工作量和成本。

  • 研发治理:如设计评审、代码评审、自动化测试、单元测试、微服务下的调测问题。

  • 运维治理:线上和线下环境隔离,持续集成环境搭建等
    ⭐️持续集成是在源代码变更后自动检测、拉取、构建和单元测试的过程。持续集成的目标是快速确保开发人员新提交的变更是正确的,新代码和原有代码可以准确地集成在一起,并且适合在代码库中进一步使用。

    ⭐️持续交付:持续集成获得的构件主要经过单元测试及部分集成测试,这些测试只能证明分支代码的合并是没有问题的,但不能保证构件的整体质量能达到产品要求,还必须将其部署到测试环境中进一步验证,这时就需要通过持续交付流程来基于持续集成生成的构件生成最终部署构件,并结合配置管理将其部署到各种测试环境中,对其进行功能及性能验证。持续交付利用持续集成生成的构件及其他必要构件进行集成编译或组装,生成部署构件,并对部署构件及其依赖的上游服务、数据库、缓存、消息队列等资源进行集成测试,以验证部署构件是否能够正常工作,以及是否满足性能上的要求。通过严格测试的部署构件就可以根据需要发布到构件库,随时被用于生产环境部署.

    ⭐️持续部署:通过持续交付环节获得部署构件之后,就可以实施持续部署。持续部署的目标是把部署构件发布到生产环境中,但这个过程并非一撮而就的。如果有预发环境,首先会把部署构件部署到预发环境进行验证,验证通过后再进行生产部署。
    持续交付主要确保有可用于部署的构件,但不一定要部署,重在体现一种能力;持续部署则是一种行为,是价值落地的手段。

《程序员的自我修养》读书笔记_logicr的博客-爱代码爱编程

第一章 谈谈职业生涯规划 一.给年轻程序员的一点启示 # 1.正确认识自己 *通过努力,你会变成你希望的样子 2.比一般人更加努力 *当你一直坚持下去时,你也会变得

《程序员的自我修养》(陈逸鹤)读书笔记_adorable_的博客-爱代码爱编程

第一章 谈职业生涯  写给年轻程序员的几点启示: 正确认识自己比一般人更努力(将成为你最大的竞争优势)适时建立个人权威遵循最佳实践保持好奇心并乐于探索新的事物抛开代码与人沟通要为优秀的人工作生活(有节制有规律的

微服务架构学习笔记(spingboot+dubbo+zookeeper)_理性&感性的博客-爱代码爱编程

微服务架构 自述 近段时间在学习微服务架构,结合前辈们的一些博客、网上的教学视频以及官方的一些技术文档,我整理了一下自己的学习笔记,一边归纳一边复习。在这里上传笔记做以后的回顾储备。 微服务架构基本概念介绍

阿里资深架构师谈:java程序员怎么做才能有最高最好的学习效率!_weixin_33695082的博客-爱代码爱编程

工作了挺久,发现有个挺有意思的现象,从程序员、高级程序员,到现在挂着架构师、专家之类的头衔,伴随着技术和能力的提高,想不明白的事情反而越来越多了。这些疑问有些来自于跟小伙伴交流,有些是我的自问自答,有些到现在也想不清楚,这篇文章就来写一写这些问题。 如何更高效的学习? 很多新人程序员一开始在学习上找不到方向,但我想在渡过了一段时间的新手期之后这类问

转:java程序员福音:通往阿里的面试通关手册,365天呕心沥血整理_普通网友的博客-爱代码爱编程

声明:本文转自头条号JavaSpring高级进阶 就目前大环境来看,跳槽成功的难度比往年高很多。一个明显的感受:今年的面试,无论一面还是二面,都很考验Java程序员的技术功底。这不马上又到了面试跳槽的黄金段,成功升职加薪,不成功饱受打击。当然也要注意,跳槽时时

SpringCloud微服务实战—翟永超 读书笔记-爱代码爱编程

SpringCloud微服务实战—翟永超 读书笔记 什么是微服务建构 微服务是系统架构上的一种风格的设计,将原本独立的系统拆分成多个小型服务。小型的服务都运行在自己独立的进程当中,服务之间基于HTTP通过Restful api进行通信写作。被拆分成的每个小型服务都围绕系统中的某一项或一些耦合度较高的业务功能进行构建。每个服务维护自身的数据存储,业务开发

杭州女程序员自述:疫情之下被迫离职,仲裁说理被公司索赔百万-爱代码爱编程

一开始,告诉你“公司裁员”,有N+1补偿; 但后来,变成了因“工作绩效不合格”而辞退; 到现在,不愿主动离职跟单位展开“仲裁”,面临赔偿公司百万元。 这样的剧情,不是电视剧,活生生发生在一位杭州女程序员(主管级别)身上。她自述理解疫情之下的公司之难,但没想到过程和结果变成最后这样——她还因为这份工作,连哺乳假都自愿舍弃。 所以不解、愤懑,无奈……之

微服务架构带来的挑战,以及微服务的9大特性!!!-爱代码爱编程

微服务是近三年来较为热门的话题,而我本人自去年接触微服务开始,就对其产生了较为浓厚的兴趣,公司也在尝试将之前的单体架构向微服务架构过渡,因此打算系统的学习一下微服务相关的知识。主要学习微服务的思想,架构设计以及SpringCloud生态的各类组件,涵盖了服务治理组件Eureka,客户端负载均衡组件Ribbon,服务容错保护组件Hystrix,声明式服务调用

字节跳动面试必问:大厂程序员35岁后的职业出路在哪?太香了-爱代码爱编程

前言 redis简单来说 就是一个数据库,不过与传统数据库不同的是 redis 的数据是存在内存中的,所以存写速度非常快,因此 redis 被广泛应用于缓存方向。另外,redis 也经常用来做分布式锁。redis 提供了多种数据类型来支持不同的业务场景。除此之外,redis 支持事务 、持久化、LUA脚本、LRU驱动事件、多种集群方案。所以在面试中我们经

【金三银四】2021年大厂程序员进阶宝典,全网首发!-爱代码爱编程

前言 在大型系统中,为了减少数据库压力通常会引入缓存机制,一旦引入缓存又很容易造成缓存和数据库数据不一致,导致用户看到的是旧数据。 为了减少数据不一致的情况,更新缓存和数据库的机制显得尤为重要,接下来带领大家踩踩坑。 一面 一面就做了一道算法题,要求两小时内完成,给了长度为N的有重复元素的数组,要求输出第10大的数。典型的TopK问题,快排算法

Java程序员必备!MySQL:介于普通读和锁定读的加锁方式-爱代码爱编程

mysql> SELECT * FROM hero; +--------+------------+---------+ | number | name | country | +--------+------------+---------+ | 1 | l刘备 | 蜀 | | 3 | z诸葛亮

《微服务设计》读书笔记一 - go微服务进阶之路-爱代码爱编程

文章目录 前言微服务什么是微服务自治性微服务的好处微服务集成一个错误的案例编排与协同关于RPC的使用REST基于事件的异步协作方式自顶向下的设计理念异步系统的复杂性设计规范可变性计划代码治理高内聚,低耦合上下文界限微服务世界中的DRY和代码重用的危险关于客户端库的使用结语参考 前言 许久未读书了,今天咱来读一读《微服务设计这本书》,豆瓣评分8