最近学习微服务架构，有人问微服务怎么就突然出现了，并且这么火了呢？其实任何事物都没有凭空出现的道理，特别是在软件架构领域，新架构、新思想的出现，一定是因为原来的架构不能满足现实需要，然后不断有先驱者进行探索、研究，并且在实践中不断总结完善，最终形成广泛后推广开来。
从微服务的视角看，我们可以发现，从原始的单体架构，到后来的分布式架构，到后来的SOA架构，每一个架构思想都是站在前人的基础上，不断完善，演进的结果。
一、单体架构时代
- 技术：asp，jsp，php
- 特点：单体时代最大的特点，前后端代码混合在一起，前端脚本嵌入各种后端代码，甚至业务逻辑代码。这种模式的好处是开发简单，部署和运营维护简单
- 业务场景：适合业务逻辑相对简单，功能比较单一的情况
- 问题：
-- 可靠性差：某个模块有bug，可能会导致整个应用崩溃
-- 技术债务：随着时间的推移，需求变更和人员迭代，会逐渐形成应用程序的技术债务，并且越积越多技术债务：随着时间的推移，需求变更和人员迭代，会逐渐形成应用程序的技术债务，并且越积越多
-- 扩展性差：单体应用只能作为一个整体，所有业务和模块耦合到一起，无法根据业务模块的需要进行伸缩单体应用只能作为一个整体应用进行扩展，无法根据业务模块的需要进行伸缩
-- 开发效率：单体架构时代，每个人都需要对项目整体结构有比较清晰的认识，否则，一个不小心，就出现拆东墙，补西墙的混乱
二、分布式架构时代
- 技术：asp，jsp，php，分布式session，SSO
- 特点：与单体时代最大的不同，在于根据业务领域进行垂直拆分，比如将一个大系统拆分，会员系统，订单系统，客服系统。。。
- 业务场景：随着业务发展，单体应用在可靠性，开发复杂性，维护性等方面已经不能满足业务需要，按照功能进行拆分就是必然的趋势。开发团队的组织结构也对应的按照不同的系统建立项目组，分别进行开发。
- 问题：虽然系统按照业务进行了垂直拆分，但是从技术上来说，并没有太大的变化，前后端代码还是耦合在一起，每个系统水平分层基本和单体时代没有差别（dao，service，controller，web）；另外
三、SOA架构时代
- 技术：rpc，http，soap，前后端通过xml通信
- 特点：在分布式时代垂直拆分基础上，进一步将项目进行拆分，典型的拆分方式是，后端Service保留dao，service层，作为service服务；controller和web层拆分到独立的web服务。
- 业务场景：将前后端独立拆分，一个最大的好处是，后端的接口可以提供公共服务，供多个web和其他service进行调用，从而实现业务统一化，相同的逻辑统一到一个服务进行处理，最大限度避免重复开发，重复意味着冗余和风险，显然统一有利于降低风险和成本。从组织结构来说，也是的前后端工作进一步解耦，只要定义好了接口，前端和后端的工作可以并行进行，使得任务分工更加细化，生产力得到提高，同时专业的人做专业的事，有利于产品质量提高。所以到目前为止，还有大量公司的技术架构处于SOA时代。
四、微服务架构时代
- 技术：http，json，vue，springboot
- 特点：SOA架构将项目分为了service+web服务，但是这种拆分是不彻底的，在web服务，还是有后端代码存在，主要是因为soap协议限制，soap协议在web端解析还是过于笨重，并且还有安全性问题。微服务架构时代的到来，彻底解决了这几个问题，首先是从通讯协议上，抛弃了soap，采用了http+json，基于http使得微服务有广泛的适用性，json的轻便，不像soap基于xml，传输大量格式数据，浪费带宽。而所有这一切的结果，就是前后端彻底的分离，使得服务的拆分粒度可以进一步细化，最近几年出现的Serveless，可以认为是服务粒度拆分到极致，就是每一个函数。
- 业务场景：微服务不仅是一种理念，也发展了一系列的工具来使得微服务架构落地，比如docker，微服务网关，微服务监控工具等
五、未来
？？？
总结
通过梳理，我们可以发现，架构的发展有两个主要的驱动力：业务需求+生产力发展需要。一方面，业务需求的不断发展，导致旧有架构出现局限，这反过来刺激我们不断寻求新的技术架构来满足更大的业务量；另一方面，业务需求的快速发展，也要求我们进一步提高生产力，提高开发效率，也促使我们寻求系统的松耦合，高内聚特性。
需要说明的是，对于具体的业务场景、项目场景来说，后来的架构并不是一定就比之前的架构好，这个还是要看实际的需要。比如微服务架构，对于一些小型的、业务单一的项目来说就明显不合适，除了增加系统复杂性，增加运营维护难度外，实在不如单体架构好