软件架构的过程（单体应用、垂直架构、SOA架构、微服务架构）

导语

*软件的架构是在不断演化的，最开始的单体应用到现在比较热门的微服务架构，这期间其实是一步步演化的。虽然属于一种递进的演化过程，但并不是说越靠后的结构越优越，没有哪种结构是在任何环境下都通用的，它们的演进其实是结合具体问题对原架构的改进。

单体应用

传统的项目架构大多是单体架构，即所有的业务功能都在一个项目中，这种结构逻辑比较简单，对于小型项目来说很实用。但随着业务量的增多，逻辑越来越复杂，项目会逐渐变得非常庞大，逻辑也会变得混乱，给维护和开发造成比较大的困难。

垂直架构

为了避免单个项目越来越大，引入了垂直架构的概念，它其实就是把原来比较大的单体项目拆分成多个小的单体项目，拆分过程是根据业务逻辑进行拆分的，比如把物流系统、CRM系统从原来的电子商城系统中抽离出来，构建成两个小的项目。这种架构虽然解决了原来单体项目过大的问题，但也带来了数据冗余、耦合性大的问题。

SOA架构

进一步地，出现了SOA架构，即service-oriented architecture，面向服务架构，它在垂直架构（对原来的单体应用进行了垂直拆分，拆分为多个小的系统）的基础上，把原来项目中的公共组件抽离出来，形成服务，为各个系统提供服务。下图中的服务层即抽取出的公共组件。系统层的多个小型系统通过ESB企业服务总线（它是项目与服务之间通信的桥梁）以及webservice调用服务，完成各自的业务逻辑。

微服务架构

SOA架构虽然进行了服务抽取，但抽取的粒度比较粗糙，系统与服务之间的耦合性很大，系统与服务的界限也不够清晰，给开发和维护造成一定的困难。于是，又出现了微服务架构。
微服务架构其实是在SOA架构上的升华，它对服务的抽取粒度更小，把系统中的服务层完全隔离出来。遵循单一原则，系统层和服务层的界限清晰，各个系统通过服务网关调用所需微服务。微服务之间通过RESTful等轻量级协议传输，相比ESB更轻量。但这种架构的开发成本比较高（因为新增了容错、分布式事务等要求），对团队的要求比较大，所以不适合小项目、小团队。

总结

总体来看，软件架构的演进过程主要是软件架构的演进过程：单体应用 --> 垂直架构 --> SOA架构 --> 微服务架构。一般来说，一个项目刚启动的时候，往往会以单体应用的形式来构建，因为项目刚起，人力、资源等都不足以支撑微服务之类的大工程架构。但随着功能越来越复杂，单体应用不足以支撑时，才会慢慢对其进行拆分，形成垂直架构、微服务架构等。*