转：

《微服务架构设计模式》读书笔记【TBC】

背景

四季度选了《微服务架构设计模式》，但是状态不怎么样，一个月过去了，才看了个开头。博客也好久没更新了，正好有小伙伴想换工作要学习，又激励了我一下，一起学习！选这本是因为公司也正在使用微服务的架构，Spring Cloud，Eureka。平时都在用，但是原理不太懂，出现点不常见的异常（百度不到的那种），就很懵*了，不知道要怎么解决，全靠猜（竟然也解决了，离谱.....）

---

第1章 逃离单体地狱

单体架构的优点

• 开发简单
• 易于对应用程序进行大规模的修改
• 测试相对简单直观
• 部署简单明了
• 横向扩展不费吹灰之力

单体地狱

即单体架构的局限性在业务快速发展后不断显现，并且越来越难以维护

• 过度复杂

• 开发速度缓慢（协同工作问题）

• 代码提交到部署周期很长，且容易出现问题

• 难以扩展

• 交付可靠性是一个挑战

• 需要长期依赖某个可能已经过时的技术栈

微服务架构

• 架构的重要性在于影响了应用的“非功能性需求”，比如 影响交付速度 的可维护性、可扩展性、可测试性
• 扩展立方体和服务

• 微服务的定义：把应用程序功能性分解为一组服务的架构风格。每一个服务都是由一组专注的、内聚的功能职责组成。
• 微服务架构作为模块化的一种形式：一般的大型应用会拆分为模块，而微服务架构即使用服务作为模块化的单元，服务可以进行独立部署和扩展。
• 每个服务都拥有自己的数据库
• 微服务与SOA的异同【没太看懂】
• 微服务架构的好处
  • 使大型复杂应用可以持续交付和部署
  • 每个服务都相对较小并且容易维护
  • 服务可以独立部署和扩展
  • 微服务架构可以实现团队的自治
  • 更容易实验和采纳新技术
  • 更好的容错性
• 微服务架构的弊端
  • 服务的拆分和定义是一项挑战
  • 分布式系统带来的各种复杂性，使开发、测试、部署变得更困难
  • 当部署跨越多个服务的功能时，需要谨慎地协调更多开发团队
  • 开发者需要思考在什么阶段使用微服务架构

微服务架构的模式语言

• 架构设计的核心是决策

微服务架构并不是“银弹”

• 光环曲线使用5个阶段描述新兴技术的发展：过热期（期望释放的顶峰，代表了对新技术的迷恋和崇拜）-> 谷底期（失望的谷，尝试之后对新技术的失望）-> 成熟期（生产高地，理解了新技术的优缺点后开始理性地使用）【果然科学的尽头是哲学】

模式和模式语言

• 没太理解，但是不影响往后看