《微服务架构设计模式》读书笔记【TBC】
作者：互联网
转：
《微服务架构设计模式》读书笔记【TBC】
背景
四季度选了《微服务架构设计模式》，但是状态不怎么样，一个月过去了，才看了个开头。博客也好久没更新了，正好有小伙伴想换工作要学习，又激励了我一下，一起学习！选这本是因为公司也正在使用微服务的架构，Spring Cloud，Eureka。平时都在用，但是原理不太懂，出现点不常见的异常（百度不到的那种），就很懵*了，不知道要怎么解决，全靠猜（竟然也解决了，离谱.....）
第1章 逃离单体地狱
单体架构的优点
- 开发简单
- 易于对应用程序进行大规模的修改
- 测试相对简单直观
- 部署简单明了
- 横向扩展不费吹灰之力
单体地狱
即单体架构的局限性在业务快速发展后不断显现，并且越来越难以维护
-
过度复杂
-
开发速度缓慢（协同工作问题）
-
代码提交到部署周期很长，且容易出现问题
-
难以扩展
-
交付可靠性是一个挑战
-
需要长期依赖某个可能已经过时的技术栈
微服务架构
- 架构的重要性在于影响了应用的“非功能性需求”，比如 影响交付速度 的可维护性、可扩展性、可测试性
- 扩展立方体和服务
- 微服务的定义：把应用程序功能性分解为一组服务的架构风格。每一个服务都是由一组专注的、内聚的功能职责组成。
- 微服务架构作为模块化的一种形式：一般的大型应用会拆分为模块，而微服务架构即使用服务作为模块化的单元，服务可以进行独立部署和扩展。
- 每个服务都拥有自己的数据库
- 微服务与SOA的异同【没太看懂】
- 微服务架构的好处
- 使大型复杂应用可以持续交付和部署
- 每个服务都相对较小并且容易维护
- 服务可以独立部署和扩展
- 微服务架构可以实现团队的自治
- 更容易实验和采纳新技术
- 更好的容错性
- 微服务架构的弊端
- 服务的拆分和定义是一项挑战
- 分布式系统带来的各种复杂性，使开发、测试、部署变得更困难
- 当部署跨越多个服务的功能时，需要谨慎地协调更多开发团队
- 开发者需要思考在什么阶段使用微服务架构
微服务架构的模式语言
- 架构设计的核心是决策
微服务架构并不是“银弹”
- 光环曲线使用5个阶段描述新兴技术的发展：过热期（期望释放的顶峰，代表了对新技术的迷恋和崇拜）-> 谷底期（失望的谷，尝试之后对新技术的失望）-> 成熟期（生产高地，理解了新技术的优缺点后开始理性地使用）【果然科学的尽头是哲学】