《微服务设计》读书笔记

导读：《微服务设计》是一本很是出彩的技术书籍，从可读性、实战技术干货方面都很是优秀，甚至让我想起了曾经读《深刻理解计算机系统》《UNIX编程艺术》这类经典好书时的感受。如下是我作的一些归纳性的读书笔记，很是但愿你们能阅读全书，挖掘更多知识。

---

1、什么是微服务：就是一些协同工做的小而自治的服务。

• 很小，专一于作好一件事：根据业务的边界来肯定服务的边界。
• 自治性：一个微服务就是一个独立的实体。服务之间均经过网络调用进行通讯，从而增强了服务之间的隔离性，避免紧耦合。这些服务应该能够彼此独立进行修改，而且某一个服务的部署不该该引发该服务消费方的变更。 

  2、微服务的主要好处

• 技术异构性：能够采用不一样的技术栈、语言、数据库或者框架。
• 弹性：弹性工程学的一个关键概念是舱壁。若是系统中的一个组件不可用了，但并无致使级联故障，那么系统的其余部分还能够正常运行。
• 扩展：使用较小的多个服务，则能够只对须要扩展的服务进行扩展，这样就能够把那些不须要扩展的服务运行在更小的、性能稍差的硬件上。
• 简化部署：在微服务架构中，各个服务的部署是独立的，这样就能够更快地对特定部分的代码进行部署。
• 与组织结构相匹配：微服务架构能够很好地将架构与组织结构相匹配，避免出现过大的代码库，从而得到理想的团队大小及生产力。
• 可组合性：能够根据不一样的目的组合不一样粒度的服务为客户提供功能。

  3、微服务的原则

• 围绕业务概念建模
  经验代表，围绕业务的界限上下文定义的接口，比围绕技术概念定义的接口更加稳定。针对系统如何工做这个领域进行建模，不只能够帮助咱们造成更稳定的接口，也能确保咱们可以更好地反映业务流程的变化。使用界限上下文来定义可能的领域边界。
• 接受自动化文化
  微服务引入了不少复杂性，其汇总的关键部分是，咱们不得无论理大量的服务。解决这个问题的一个关键方法是，拥抱自动化文化。前期花费必定的成本，构建支持微服务的工具是颇有意义的。自动化测试必不可少，由于相比单块系统，确保咱们大量的服务能正常工做是一个更复杂的过程。调用一个统一的命令行，以相同的方式把系统部署到各个环境是一个颇有用的实践，这也是采用持续交付对每次提交后的产品质量进行快速反馈的一个关键部分。
  考虑使用环境定义来帮助你明确不一样环境间的差别，但同时保持使用统一的方式进行部署的能力。考虑建立自定义镜像来加快部署，而且建立全自动化不可变服务器，这会更容易定位系统自己的问题。
• 隐藏内部实现细节
  为了使一个服务独立于其余服务，最大化独自演化的能力，隐藏实现细节相当重要。限界上下文建模在这方面能够提供帮助，由于它能够帮助咱们关注哪些模型应该共享，哪些应该隐藏。服务还应该隐藏它们的数据库，以避免陷入数据库耦合，这在传统的面向服务的架构中也是最多见的一种耦合类型。使用数据泵或事件数据泵，将跨多个服务的数据整合到一块儿， 以实现报表的功能。 
  在可能的状况下，尽可能选择与技术无关的API。这能让你自由地选择使用不一样的技术栈。请考虑使用REST，它将内部和外部的实现细节分离方式规范化，即便是使用RPC，你仍然能够采用这些想法。
• 让一切都去中心化
  为了最大化微服务能带来的自治性，咱们须要持续寻找机会，给拥有服务的团队委派决策和控制权。在这个过程初期，只要有可能，就尝试使用资源自助服务，容许人们按需部署软件，使开发和测试尽量简单，而且避免让独立的团队来作这些事。 
  在这个过程当中，确保团队保持对服务的全部权是重要的一步，理想状况下，甚至可让团队本身决定何时让那些更改上线。使用内部开源模式，确保人们能够更改其余团队拥有的服务，不过请注意，实现这种模式须要不少的工做量。让团队与组织保持一致，从而使康威定律起做用，并帮助正在构建面向业务服务的团队，让他们成为其构建的业务领域的专家。一些全局的引导是必要的，尝试使用共同治理模型，使团队的每一个成员共同对系统技术愿景的演化负责。
  像企业服务总线或服务编配系统这样的方案，会致使业务逻辑的中心化和哑服务，应该避免使用它们。使用协同来代替编排或哑中间件，使用智能端点确保相关的逻辑和数据，在服务限界内能保持服务的内聚性。
• 可独立部署
  咱们应该始终努力确保为服务能够独立部署。甚至当须要作不兼容更改时，咱们也应该同时提供新旧两个版本，容许消费者慢慢迁移到新版本。这可以帮助咱们加快新功能的发布速度。拥有这些微服务的团队，也能愈来愈具备自治性，由于他们不须要在部署过程当中不断的作编配。 当使用基于RPC的集成时，避免使用像Java RMI提供的那种使用生成的桩代码，紧密绑定客户端/服务器的技术。
  经过采用单服务单主机模式，能够减小部署一个服务引起的反作用，好比影响另外一个彻底不相干的服务。请考虑使用蓝/绿部署或金丝雀部署技术，区分部署和发布，下降发布出错的风险。使用消费者驱动的契约测试，在破坏性的更改发生前捕捉它们。
  请记住，你能够更改单个服务，而后把它部署到生产环境，无需联动地部署其余任何服务，这应该是常态，而不是例外。你的消费者应该本身决定什么时候更新，你须要适应他们。
• 隔离失败
  微服务架构能比单块架构更具弹性，前提是咱们了解系统的故障模式，并作出相应的计划。若是咱们不考虑调用下游可能会失败的事实，系统会遭受灾难性的级联故障，系统也会比之前更脆弱。
  当使用网络调用时，不要像使用本地调用那样处理远程调用，由于这样会隐藏不一样的故障模式。因此确保使用的客户端库，没有对远程调用进行过分的抽象。
  若是咱们的心中有反脆弱的信条，预期在任何地方都会发生故障，这说明咱们正走在正确的路上。请确保正确设置你的超时，了解什么时候及如何使用舱壁和断路器，来限制故障组件的连带影响。若是系统只有一部分行为不正常，要了解其对用户的影响。知道网络分区可能意味着什么，以及在特定状况下牺牲可用性或一致性是不是正确的决定。
• 高度可观察
  咱们不能依靠观察单一服务实例，或一台服务器的行为，来看系统是否运行正常。相反，咱们须要从总体上看待正在发生的事情。经过注入合成事务到你的系统，模拟真实用户的行为，从而使用语义监控来查看系统是否运行正常。聚合你的日志和数据，这样当你遇到问题时，就能够深刻分析缘由。而当须要重现使人讨厌的问题，或仅仅查看你的系统在生产环境是如何交互时，关联标识能够帮助你跟踪系统间的调用。

  4、对于微服务的建议

• 考虑首先先构建单块系统，当稳定后再进行拆分
  你越不了解一个领域，为服务找到合适的限界上下文就越难。服务的界限划分错误，可能致使不得不频繁地更改服务间的协做，而这种更改为本很高。因此，若是你不了解一个单块系统领域的话，在划分服务以前，第一件事是花一些时间了解系统是作什么的，而后尝试识别出清晰的模块边界。另外，对已有的东西进行分类，要比对不存在的东西进行分类要容易得多。
• 演进式架构理念
  微服务架构会给你带来更多的选择，也须要你作更多的决策。相比简单的单块系统，在微服务的世界中，作决策是一个更为常见的活动。你必定会在一些决策上出错，因此尽可能缩小每一个决策的影响范围。即便错了，也只会影响系统的一小部分。学会拥抱演进式架构的概念，在这种概念下，系统会在你学到一些新东西以后扩展和变化。不要去想大爆炸式的重写，取而代之的是随着时间的推移，逐步对系统进行一系列更改，这样作能够保持系统的灵活性。
• 一样很重要的一点：微服务不是银弹。

  5、对于架构师的见解

• 演化式架构师：就如同城市规划师（优化城市布局，使其易于现有居民生活，同时也考虑一些将来的因素），应该设计出一个合理的框架，在这个框架下能够慢慢演化出正确的系统；要专一在大方向上，只在颇有限的状况下参与到很是具体的实现中来。他们须要保证系统不但可以知足当前的需求，还可以应对未来的变化。并且他们还应该保证在这个系统上工做的开发人员要和使用这个系统的用户同样开心。
• 一个演化式架构师应该承担的职责：
  • 愿景：确保在系统级有一个通过充分沟通的技术愿景，这个愿景应该能够帮助你知足客户和组织的需求。
  • 同理心：理解你所作的决定对客户和同事带来的影响。
  • 合做：和尽可能多的同事进行沟通，从而更好地对愿景进行定义、修订及执行。
  • 适应性：确保你的客户和组织须要的时候调整技术愿景。
  • 自治性：在标准化和团队自治之间寻找一个正确的平衡点。
  • 治理：确保系统按照技术愿景的要求实现。