引子
软件架构从最初的单体架构，到垂直架构，到SOA架构，再到现在流行的微服务架构，一直处在演进与发展中。演进的过程本质上是在不停的满足愈发复杂的业务需求，因此笔者更倾向称呼它们为“业务架构”。
每一次架构的演进都是基于原有架构的特性再结合实际的业务场景而进行的改进，但这并不意味着越新的架构就越优，每一种架构都有其所适用的场景。
1 单体架构
单体架构，就是将所有的功能集中在一个工程中。
对于小型项目来讲，单体架构有着得天独厚的优势，开发、部署都很简单，成本低、周期短、效率高，即使在微服务架构流行的今日，单体架构仍非常适合小型项目。
但随着业务功能的不断增加，单体架构的工程会愈发的庞大、臃肿，对开发、运维等各类工作均会带来不小的负面影响：工程大了，文件多了，那么若没有强力的开发规范及约束手段，工程就难免混乱；工程编译及启动需要更长的时间，工作电脑配置不足时，甚至会出现IDE使用卡顿的情况；在生产环境下对工程进行全量替换（尤其是长久没有更新过的情况下）风险难以估量。
单体架构作为一个整体，相较于SOA架构、微服务架构这种拆分的架构，还有两个明显的缺点：单体架构存在着因为一个bug而拖死整个系统的风险；单体架构无法针对某一类高峰业务进行硬件扩展，只能作为整体进行扩展。
2 垂直架构
垂直架构，其实就是根据业务特性将原有的单体架构项目拆分成多个项目。业务拆分的原则应该满足可以独立运行、相互间不影响。
垂直架构所拆分出的项目在体量上有所缩减，不过本质上依然是单体架构，具有单体架构固有的优缺点。
垂直架构控制了工程体量，将原有系统的流量分散到多个子系统中，可以对子系统进行单独扩展。同时，垂直架构也带来了新的问题：
- 部分功能的重叠，也就是我们常说的“重复造轮子”。
- 数据冗余，比如任何一个系统都需要用户信息，这些数据往往又需要同步，多以数据库层面的同步手段为主，比如Oracle的DataGuard，有时甚至可以直接通过DBLink、Synonym、View等方式粗暴的解决，当然也有通过系统间的接口进行同步处理的。
- 愈发避无可避的系统间交互（信息孤岛的打破），一个系统需要集成、对接多个不同系统的接口。
说点题外话，从理论上的架构角度去看，垂直架构是因为单体架构过于庞大进而拆分而来。有意思的是，实际中会存在这样的场景，从商业项目的角度出发，一个大型系统在投标之际就已经被规划为多个子系统，这些子系统由不同厂商中标，自然而然的形成了垂直架构的模型。
3 SOA架构
SOA (Service-Oriented Architecture)，即面向服务的架构。
百度百科中给出的定义：
面向服务架构（SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）进行拆分，并通过这些服务之间定义良好的接口和协议联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。
这个概念有些难理解，我们可以从垂直架构的不足来理解SOA架构做了什么。
同样都是对系统进行拆分，SOA在垂直架构的基础上，抽离出重叠的功能作为公共的服务，来解决重复造轮子的问题。拆分出的系统或服务，通过ESB（Enterprise Service Bus）企业服务总线来进行规范的、统一的信息交互，解决调用混乱的问题。
SOA相较于垂直架构，对于业务的拆分更为清晰，公共的组件服务职责单一，可扩展性强。不再强行打通数据库层面的壁障，让数据重新回到隔离状态，信息孤岛问题全部由接口来解决，提高了系统的安全性。ESB将原先的点对点交互模式转换为了总线式集成的交互模式，降低了系统间的耦合度，同时也降低了系统间相互集成的难度与成本。
凡事都有两面，服务的抽取解决了重复造轮子的事情，但是对于各个系统来说，能够复用轮子真的很重要么？所付出的代价是愿意承受的么？轮子的抽取，使得系统与服务之间高度耦合；通过ESB进行中转交互，性能一定会有所损耗，且所有系统间的信息都通过ESB来传递，ESB很明显的会成为整个系统内的瓶颈所在，一旦ESB宕了，所有系统都会受到牵连。
SOA要求企业在技术与业务上均做出改变，然而却很难让他们看到足够的好处。因此，SOA并没有在企业中得到很好的推广。
4 微服务架构
在互联网已经相当成熟的时代，互联网业务量剧增，变化又十分频繁，互联网技术团队对敏捷开发、持续交付、系统弹性扩展、资源利用优化等课题十分关注，微服务架构在这样的条件中，取得了良好的实践效果。
微服务架构将单一的应用程序拆分为一组小型服务，每个服务都是围绕业务能力进行构建，能够独立开发、测试、部署，服务间采用轻量级的通讯机制。
抛开ESB，是不是感觉微服务架构与SOA有些相似呢？我们可以将微服务看做是SOA的子集，微服务可以说是粒度更细、更能满足当前互联网需求的SOA的实现方式。更细的拆分粒度有利于资源的重复利用与精准的伸缩扩容，服务间的通信协议更加轻量，对于DevOps有着更好的支持。相较于SOA，微服务之所以能够成功，不仅仅是因为架构本身能够匹配业务痛点，更是因为整个互联网环境及配套工具链（如云、容器等）的成熟，才使得微服务架构有了最佳实践。
不要低估了微服务架构带来的复杂性！微服务架构具有分布式架构固有的复杂性，如服务间需要相互通信、可能产生的分布式事务问题等；一套微服务应用的部署与运维相当麻烦，你首先需要缓存、消息、反向代理、监控平台、注册中心等等中间件的支持，接下来是大量应用实例的规划与部署，同时产生大量的配置信息需要去管理，成熟的部署运维需要寻求高度自动化的方案；微服务体系下，服务调用关系复杂，使得问题排查与定位的难度也大大增加。
【文章转自：美国站群服务器 http://www.558idc.com/mgzq.html处的文章,转载请说明出处】