系统架构的演变

1、集中式架构

当网站流量比较小的时候，只需要一个应用，将所有的功能部署在一起，以减少部署成本，服务器成本等等。所有的增删改查功能集中在一起。
就拿我写的一个简单的微博项目来说：

好处：开发成本低
缺点：
代码耦合，开发维护麻烦
无法针对单个模块做维护或者优化
单点容错率低，一台服务器，服务器挂了整个项目就都用不了了
并发能力低

水平拆分

水平拆分：在集中式的基础之上，将请求和业务分离出来

垂直拆分

优点：
系统拆分后实现了流量分担，并发问题得到了解决
可以维护和优化单个模块
方便水平扩展，负载均衡容错率高
缺点：
系统之间相互独立，会有很多重复开发的工作，影响了开发效率

分布式架构

当垂直拆分越来越多的时候，应用之间的相互调用不可避免，将核心的业务抽离出来，形成了独立的服务，使得前端应用能快速的响应市场的需求。此时用于提高业务复用及整合的分布式调用是关键的问题

优点：将基础的服务进行了抽离，服务之间可以相互调用，提升了代码的复用和开发效率
缺点：系统间的耦合变高了，调用的关系错综复杂。难以维护

面向服务架构：
当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐出现，此时出现一个调度中心基于访问压力实时管理，提高集群利用率，此时用于提高激励利用率的资源调度和治理中心就是关键

之前出现的问题：
服务过多，需要管理每个服务的地址
耦合度变高
调用关系错综复杂，难以管理。

服务治理：
注册中心：实时自动的服务注册和发现，不需要人为记录服务的地址
服务的自动订阅，服务列表自动推送，服务调用透明化，无需再关系依赖
动态的监控服务状态

缺点：
服务之间有依赖关系，可能一个环节出问题，有较大影响
关系复杂，运维和测试部署都很困难

微服务

SOA是面向服务的架构。微服务，也是服务。是对于系统进行拆分。因此两者容易混淆。但是肯定是有差别的。
微服务：
微服务，每个微服务都对应唯一的业务能力，单一职责。
微，拆分粒度很好。比如用户管理可以单独作为一个服务。
微服务，每个服务都对外暴露rest风格接口。不需要关心服务的具体实现，做到和平台语言无关。
团队独立，每个服务可以是一个独立的开发团队，人数不用很多
技术独立，面向服务，提供rest接口，使用的技术和其他人没有关系
前后端分离，后台不需要为PC，移动端单独再开发接口
数据库分离，每个服务可以有自己的数据源
部署独立，服务之间可以调用，但是服务重启不影响其他的服务，有利于持续继承和交付