前言
没有最好的架构，适合业务发展的架构就是好架构。互联网公司的架构从来都不是一蹴而就的，都是随着业务不断发展来推进架构的不断演进。
一、单体架构
早期互联网产品用户量少，数据量小，单个应用服务器基本就可以满足需要。
应用server、文件服务、数据库服务都是单体应用。优点是容易开发、部署和测试。缺点是耦合度高、缺乏故障转移，在升级维护中必须进行停机，不能满足高并发和高可用
二、水平分层架构
水平分层架构即从水平方向上进行拆分，如下图所示：
水平分层架构从水平方向物理分成多个独立的进程包含：
1.网关层
2.业务逻辑层
3.数据访问层
4.数据存储层
每层直接逻辑解耦
三、SOA架构
分布式架构出现之后，随着应用的更细力度的拆分，逐渐呈现了一个相互依赖、公共的模块，这些模块大都依赖于相同的逻辑或者功能代码。这时候就需要把这些应用的公用模块提出来，采用独立部署统一管理的方式，提高重用度，这就是服务导向架构（SOA）。
SOA其实是一种理念，它的主要特性：面向服务的计算，服务之间松散耦合，支持服务的封装，服务注册和自动发现。但是SOA并没有定义出具体的实现方式，目前一种主要的实现方式是企业服务总线（Enterprise Service Bus，ESB），ESB的根本目标是解决异构系统的连通性，通过协议转换、消息解析、消息路由把服务提供者的数据传递到服务消费者。所以SOA的中心化虽然重，但是会解决一些公用逻辑的问题。
四、微服务架构
基于SOA的系统架构实现了松耦合，系统之间通过服务接口（Service API）和中心化管理的企业服务总线（ESB）进行交互, 但这种拆分往往是业务系统的一种垂直拆分，拆分的子系统随着业务的复杂耦合仍然面临难以开发和维护的问题。因此更细粒度的拆分变得必要，将子系统功能进一步拆分，变成一项项的服务。系统分布式架构，服务去中心化实现，也即微服务的思想。
敏捷开发专家Martin Fowler 在2014年定义了微服务架构。微服务架构风格是一个系统，由一套独立运行的微服务组成， 这些服务是围绕业务功能构建的，服务关注单一业务，服务间采用轻量级的通信机制（通常是HTTP资源的API），可以全自动独立部署，可以使用不同的编程语言和数据存储技术。
微服务架构通过业务拆分实现服务组件化，通过组件组合快速开发系统，业务单一的服务组件又可以独立部署，使得整个系统变得清晰灵活。但是大量的分布式服务又使得架构实现面临问题，如服务注册发现，服务统一接入和权限控制，服务的负载均衡，服务配置的集中管理，服务熔断，服务监控等。所以在微服务架构中除了业务服务组件外通常会引入服务注册发现组件来进行服务治理，引入服务网关组件来提供统一入口和权限控制，引入负载均衡组件来提供客户端或服务器端的负载均衡，引入集中配置组件来提供服务集中管理，引入熔断器组件来提供服务熔断，引入服务追踪组件来提供服务监控等。因此微服务架构是由这些基础的服务组件和业务微服务组件共同组成。基本的微服务架构如图所示：
微服务架构实现了业务的解耦，使系统具备了良好的扩展性和伸缩性，单个服务组件可以独立部署，便于组件的开发测试部署和维护，服务自治也可以将数据管理去中心化，容器化部署平台也降低了测试、部署和运维的难度，使软件开发迭代更加敏捷快速，但分布式系统固有的难题（如分布式事务等）在微服务架构中也依然存在。
