单体架构的好处
- 应用开发简单；
- 一个Git，可以看到代码全貌
- 易对应用程序进行大规模修改；
- 测试相对简单直观；
- 部署简单明了；
- 横向扩展不费吹灰之力；多实例+负载均衡即可。
单体架构的问题
- 过度复杂性会吓退开发者；
- 理解复杂
- 代码难理解—更改时容易出错—冗余代码—-更复杂
- 开发速度慢；
- IDE卡顿，编译慢，启动慢。
- 从代码提交到实际部署的周期很长，容易出问题；
- 不同模块分了团队后，团队的时间不一致。
- A团队的代码可能对B团队产生影响。
- 难以扩展；
- 有的模块需要硬盘，有的模块需要CPU，这样就必须把服务器配置拉满，造成浪费。
- 交付可靠的单体应用是一项挑战；
- 没有隔离。
- 需要长期依赖某个可能已过时的技术栈；
- 难以重构，需要整体重写。
- 难以重构，需要整体重写。
系统的扩展
- X轴：负载均衡，随机算法、平均算法，复制多个单体就好了。
- Z轴：根据请求路由，有针对地扩容。
- Y轴：功能性拆分，将应用拆分成服务。
微服务的特点
- 根据业务拆分服务，独立开发、测试、部署，并且拥有自己的数据库。
- 服务间采用轻量级的通信机制。
和SOA的区别
- SOA是全局数据库，微服务的独立数据库。
- 微服务的拆分更小。
- SOA的通信方式更重，采用了ESB企业总线，微服务采用的RPC。
微服务的好处
- 使大型的复杂应用程序可以持续交付和持续部署
- 自动化测试—-持续交付和持续部署
- 独立部署
- 开发团队自主且松散耦合
- 每个服务都相对较小并容易维护；
- IDE快，启动快。
- 提高调试、部署等环节效率。
- 服务可以独立部署；
- 服务可以独立扩展；
- 有针对地选择服务器。
- 微服务架构可以实现团队的自治；
- 每个团队可以有自己的技术和管理方法。
- 更容易实验和采纳新技术；
- 方便试错和迭代。
- 更好的容错性；
- 故障隔离了，进程和数据库都隔离了。
- 故障隔离了，进程和数据库都隔离了。
微服务的弊端
- 服务的拆分与定义是一项挑战；
- 没有具体的、良好的算法可以完成拆分工作，这让服务的拆分更像一门艺术。
- 如果拆分的不好，会成分布式单体，会包含单体和微服务两者的弊端。
- 分布式系统带来各种复杂性，使开发、测试和部署变得困难；
- 跨服务的事务和查询。
- 数据一致性。
- 需要高度自动化。
- 当部署跨越多个服务的功能时需要谨慎地协调更多开发团队；
- 需要根据服务依赖来制定开发计划。
- 开发者需要思考到底应该在应用的什么阶段使用微服务架构；
- 初创公司应该从单体开始。
新架构的推进
银弹现象：
过热期（迷恋和崇拜）—- 低谷期（失望）—- 成熟期（生产力的高地，理性地使用）
理性地看待新技术。
骑大象的人：大象代表思维中情绪化的部分，它完成了绝大部分决策。骑大象的人代表理性的部分，用来对大象的决策进行判断。
团队增大，沟通成本也会迅速增加，解决之道就是将大团队划分成小团队。
让团队“自治”。
持续交付：
持续交付能够以可持续的方式安全、快速地将所有类型的更改(包括新功能、配置更改、错误修复和实验)交付到生产环境或用户手中
- 部暑频率:软件部署到生产环境中的频率。
- 交付时间:从开发人员提交变更到变更被部署的时间。
- 平均恢复时间:从生产环境问题中恢复的时间。
- 变更失败率:导致生产环境问题的变更提交百分比。
微服务带来的管理问题
- 失落和放弃：改变总是痛苦的，要脱离舒适区，人们会叨念之前的好。
- 中立区：纠结并开始学习新的工作方式。
- 新的开始：体会到了新工作方式的好，开始热情地拥抱新的工作方式。