微服务笔记：百万程序员都读过的两本书！

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

《微服务设计》

作者：[美] Sam Newman

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

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

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

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

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

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

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

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

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

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

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

• 运维治理：线上和线下环境隔离，持续集成环境搭建等
  ⭐️持续集成是在源代码变更后自动检测、拉取、构建和单元测试的过程。持续集成的目标是快速确保开发人员新提交的变更是正确的，新代码和原有代码可以准确地集成在一起，并且适合在代码库中进一步使用。
  
  ⭐️持续交付：持续集成获得的构件主要经过单元测试及部分集成测试，这些测试只能证明分支代码的合并是没有问题的，但不能保证构件的整体质量能达到产品要求，还必须将其部署到测试环境中进一步验证，这时就需要通过持续交付流程来基于持续集成生成的构件生成最终部署构件，并结合配置管理将其部署到各种测试环境中，对其进行功能及性能验证。持续交付利用持续集成生成的构件及其他必要构件进行集成编译或组装，生成部署构件，并对部署构件及其依赖的上游服务、数据库、缓存、消息队列等资源进行集成测试，以验证部署构件是否能够正常工作，以及是否满足性能上的要求。通过严格测试的部署构件就可以根据需要发布到构件库，随时被用于生产环境部署.
  
  ⭐️持续部署：通过持续交付环节获得部署构件之后，就可以实施持续部署。持续部署的目标是把部署构件发布到生产环境中，但这个过程并非一撮而就的。如果有预发环境，首先会把部署构件部署到预发环境进行验证，验证通过后再进行生产部署。
  持续交付主要确保有可用于部署的构件，但不一定要部署，重在体现一种能力；持续部署则是一种行为，是价值落地的手段。