写在前面的话
Stay Hungry Stay Foolish！！！
每天进步一点点！！！
《每日一读》是博主每日学习的一篇文章所记录的笔记，大多数是提取文章中关键内容而成；文章类型不限，内容不限。
意义：培养自己的阅读能力，学习更多的知识
郑重声明：如果涉及到文章侵权深感抱歉，请及时联系我我会第一时间删除，谢谢！！
总结
细细体会服务架构演进的步骤来看，无非是在不断的解决新的问题而产生新的架构，这就好似在这条路上不断循环
- 确定新的问题域
- 抽象新的问题域，产生新解决方案
- 出现新的问题域
微服务架构不是这条路上的终点，这就好比现在又早就出现的云原生、Serverless、ServiceMesh、PAAS、SAAS等，当然这些出现的新的解决方案也都是终点；
在未知的道路上很崎岖，但是却永远都不会有终点的那一天，我们要不断的探索未知，解决未知。
正文
关键字
- 前后端分离
- 分布式
- 微服务
- DDD（领域驱动设计）
演变路径
- 单体应用：数据库、服务部署在同一台机器上
- 单数据库多应用架构
- 读写分离数据库架构 + 缓存(CDN、Redis)
- 使用消息队列的架构
- 面向服务的架构（SOA）
- 微服务架构：API-Gateway、服务发现、熔断机制、服务部署
演进
1）单体应用 -> 单数据库多应用架构
原因：用户增加、业务变得复杂、系统响应速度变慢
方案：水平扩容
2）单数据库多应用架构 -> 读写分离数据库架构
原因：系统业务功能增加，数据库查询成为瓶颈，查询时间慢，整体响应变慢
方案：主从分离，CDN及业务缓存(Redis)
3）读写分离数据库架构 -> 消息队列架构
原因：存在耗费大量服务器资源及耗时较长的业务；流量瞬增场景
方案：消息队列
4）消息队列架构 -> 面向服务架构(SOA)
原因：系统复杂度增加、参与开发者变多
方案：单服务拆分为多个服务
典型案例：SSO单点登录
5）面向服务架构(SOA) -> 微服务架构
原因：系统复杂度增加，不同应用和数据之间互相依赖，逻辑纠缠不清，项目的部署进入了混沌状态
方案：微服务，解耦；将不同职责的服务独立部署，从而实现服务内部高内聚，服务之间低耦合的效果，让开发变得更为灵活!
摘录
架构也很难一开始就设计的完美，架构不是设计出来的，甚至不能被设计，只能在需求的变化中不断演进。架构师的工作不太像建筑师那样构建大的蓝图，更像药剂师那样对症治病、照方抓药。就像《大教堂与集市》说的那样，“软件很大程度上是一个服务行业，虽然长期以来都毫无根据地被错认为是制造行业。”
就像生命在自然环境中不断适应，才得以演化；我们的架构需要根据需求中不断改进，才得以敏捷。
