传统架构– 软件架构– 图一
传统架构– 硬件架构– 图二（仅供参考）
传统架构– 企业组织架构– 图三（仅供参考）
这个就要从历史上去说了，在计算机发展过程中，计算机慢慢的渗透进个人、企业等用户的场景中，但那时计算机价格昂贵，对使用者有一定的门槛要求。
使计算机普及率并不高，而计算机更多的是用于打字、运算等操作，只在部分领域内普及，且受限于硬件技术（集成电路技术刚发展也没多少年）与软件技术（编程语言等）的局限，使当时的程序员可选择性的设计不多，局限性太多，也没有多少人料到计算机的发展的如此之快，即便料到，在当时的环境下（各种标准规范未同一，系统平台混乱等等…）考虑更多的是把程序制作出来，用户可以正常使用才是最重要。（不讨论从第一台电脑造到集成电路发展的历史，有兴趣自己去查资料。）
架构说明：
全部功能集中在一个项目内。
架构优点：
开发效率高、开发周期短。
架构缺点：
技术栈受限，只能使用一种语言开发。
导致不易于扩展，因每次一更改等需要重新更新/打包整个项目，导致维护困难。
垂直架构
垂直架构– 软件架构– 图一
垂直架构– 硬件架构– 图二（仅供参考）
垂直架构– 企业组织架构– 图三（仅供参考）
为什么会出现垂直架构？
随着互联网的发展，用户越来越多，软件技术也得到了很大的发展，人们开始研究一些技术使其与底层硬件交互会更加友好等。
及某系统流量访问某模块占比很高，而其他模块没有什么流量访问，如果都部署到一起占用的资源就浪费了，如果分开部署，流量高的部署到一台高性能服务器，而流量低的部署到一台普通的服务器，两个模块之间的交互用WebService、RPC等方式进行访问。
那样就可以解决上述传统架构的缺点问题
架构说明：
按照业务进行切割，形成小的项目，项目直接通过RPC等方式通信，交换数据等。
架构优点：
涵盖了传统架构的优点，另外项目不会无限扩大，技术栈可扩展（不同的系统用不同的编程语言编写）
架构缺点：
功能集中在一个项目中，不利于开发、扩展、维护。
系统扩张只能通过集群的方式。
项目之间功能冗余、数据冗余、耦合性强。
面向服务架构（SOA）
服务架构– 软件架构– 图一
服务架构– 硬件架构– 图二（仅供参考）
服务架构– 企业组织架构– 图三（仅供参考）
为什么需要面向服务架构？
在垂直架构中可以看到，物流系统有用户管理，CRM系统有用户管理，为什么还要重复去写？
人总是聪明的，很快的把一些生活中的例子作为参考去做设计（生活中，人们需要实现某种需求时，通常是去看市场是否有这种工具在售，人们不会去关心这个东西是怎么做成的），把用户管理模块作为一个服务去对外提供，。
用户管理模块作为一个服务提供出去，人们怎么去找到这个服务呢？各系统的用户信息结构可能不一样所接入的接口可能不一样？
服务交互都要经过ESB（企业服务总线），ESB帮助你去寻找到你所需要的服务，且帮助你寻找到所需要的接口，可以理解为一个过滤和寻址的过程。
架构说明：
将重复功能或模块抽取成组件的形式，对外提供服务，在项目与服务之间使用ESB（企业服务总线）的形式作为通信的桥梁，使用RPC等方式进行通信。
架构优点：
重复功能或模块抽取为服务，提高开发效率、可重用性高、可维护性高。
可以针对不同服务制定对应的技术方案。
接口耦合度低
架构缺点：
各系统之间业务不同，因此很难确认功能或模块是重复的，不利于开发和维护
抽取服务的粒度大，系统和服务之间耦合度高
微服务架构
微服务架构– 软件架构– 图一
微服务架构– 硬件架构– 图二（仅供参考）
微服务架构– 企业组织架构– 图三（仅供参考）
有了SOA架构为什么会出现微服务架构？
SOA架构有局限性，就是所有的接口都需要走ESB，如果不同的编程语言开发子系统，而这个编程语言对于某种RCP协议支持是最友好的，而ESB规则限定其只能使用ESB的规定协议。
而这里的网关是用于数据过滤等业务场景。
架构说明：
在服务治理架构上延伸，抽取的粒度更细，尽量遵循单一原则，采用轻量级框架协议传输。
架构优点：
去中心化。
粒度更细，有利于提高开发效率。
可以针对不同服务制定对应的技术方案。
去中心化的思想，不在使用ESB作为通信的桥梁，服务、系统之间可以相互访问。
适用于产品迭代周期短
架构缺点：
粒度太细导致服务太多，维护成本高。
负载均衡、事务等问题对技术团队的挑战及成本问题。
补充
其实观察一下，不止是企业、架构的发展是如此，计算机硬件也是如此，从一开始的运算器不断的发展到系统总线、寄存器、缓存、主存等，不断的越来越细粒度。
