1、为什么使用微服务架构

1.1   单体地狱

1.1.1   单体应用的好处

l   开发简单，IDE及其他开发工具只需要建立一个单独的工程

l   测试简单，通常只需要端到端测试

l   部署简单，直接替换文件或将应用替换到Web容器即可

l   便于大规模修改，对代码或数据库模式修改后直接构建和部署即可

l   便于横向扩展，直接部署多个实例，通过负载调度即可

1.1.2   单体应用的缺点

l   开发复杂度持续增长，容易陷入代码库过大导致难以理解，导致修改易出错，导致代码更复杂的恶性循环

l   开发速度缓慢，IDE加载缓慢，应用启动加载缓慢

l   代码从提交到部署的周期长且易出错，每次都需要覆盖整个应用，尤其在手动或自动化的测试等环节

l   难以扩展，难以实现各模块对资源的差异化诉求，如计算密集型、存储密集型等

l   可靠性无法保障，因运行在同一进程而难以做到故障隔离，一个模块的错误可能导致系统整体不可用

l   技术栈难以更新，系统的整体依赖导致难以针对热点模块或新模块应用新技术

1.2   微服务架构

1.2.1   微服务架构的好处

l   便于大型的复杂的应用进行持续交付和持续部署

n   高可测试性，每个服务相对较小，易于自动化测试的实现

n   快速部署，服务间独立部署，减少与其他服务团队的协调

n   团队间松耦合，服务的松耦合决定团队的松耦合，降低协调开销

l   每个服务相对较小且易于维护，便于开发者理解服务的代码，保障IDE的效率，服务启动效率高

l   各服务可独立扩展，便于针对服务的特点（计算密集型、存储密集型等）进行差异化部署

l   容错性强，一个服务出错不会影响其他服务，故障隔离

l   易于新技术引入，各服务间不会形成技术栈捆绑

1.3   其他

面向对象、微服务架构等思想类模式的出现，通常是伴随这应用程序的规模和复杂性的爆发。即这些编程思想是为了解决实际问题，而这类问题通常具备高复杂性。

也就是说，并非所有场景都需要应用新的思想，而要结合应用的实际情况判断，尤其在系统初期，通常首个版本的快速发布才是重点（因为需要验证产品的价值），此时使用传统的开发方式往往更加合适。

而在系统成长到一定程度时，则需要考虑通过应用更加适合的思想来降低软件危机出现的风险，通过重构使软件的技术含量与商业价值相匹配，才不会被时代所抛弃。