大家好，我是老猿，今天继续专题【老猿说架构】，文章仅代表作者观点，如有不同观点论述欢迎拍砖交流。好，废话不说，直接进入主题。
架构风格是一种架构设计理念或思想，跟建筑风格类似，如欧式、美式、中国式和现代等风格建筑，代表一种建筑设计理念或思想，从架构定义看很容易理解架构风格即是构件粒度+交互模式，而架构模式是架构风格的具体解决方案，每种架构风格都可以有不同的架构模式组合实现，那么老猿跟大伙聊聊如下5种常见的架构风格。
1：单体系统架构
构件粒度：面向应用级，即系统级别
构件交互模式：整体应用集群部署内部交互
特点：
1)所有业务功能集中在1个系统中，业务模块实现强耦合低内聚。
2)应用服务与数据库存储层分开部署。
3)集群部署应用和数据库服务提高系统支撑的性能。
优点：
1)架构简单，前期开发周期短，成本低，适用于简单而小的项目开发。
缺点：
1)全部业务功能集中在1个系统中，难于开发、扩展及维护，不适用大型项目。
2)系统性能扩展只能通过扩展集群结点，成本高、很快就到系统容量瓶颈。
2：垂直架构
构件粒度：面向子系统级别
构件交互模式：子系统分开集群部署，子系统之间数据同步并分布式交互
特点：
1)以单体架构系统进行垂直拆分成一个一个子系统构件构成。
2)子系统之间存在数据冗余，耦合性较大
3)子系统之间接各种方式数据同步满足业务需要。
优点：
1)系统架构简单，前期开发成本低，周期短，适用于中小型项目。
2)通过垂直拆分，原来的单体不至于成为一个巨石系统。
缺点：
1)跟单体架构类似，全部业务功能集中在几个子系统中，同样难于开发、扩展及维护，不适用大型项目。
2)跟单体架构类似，系统性能扩展只能通过扩展集群结点，成本高、很快系统容量瓶颈。
3：SOA架构
构件粒度：面向功能组件服务，即组件级别
构件交互模式：组件服务分布式交互为主
特点：
1)基于SOA的架构思想将重复公用的功能抽取为组件，以组件服务的方式给各子系统提供服务。
2)各组件服务之间采用webservice或rpc等方式进行通信交互。
3)ESB企业服务总线作为子系统与子系统之间通信的桥梁。
优点：
1)将重复共性功能抽取为组件服务，提高开发效率和复用性、可维护性。
2)可针对不同组件服务特点制定集群及优化方案。
3)采用ESB减少系统中的接口耦合。
缺点：
1)系统与组件服务的界限模糊，不利于开发及维护。
2)使用了ESB其服务接口协议不固定且种类繁多难于维护。
3)抽取服务的粒度过大，系统与服务之间耦合度很高。
4：微服务架构
构件粒度：面向更细粒度的服务，即小业务功能服务级别
构件交互模式：业务功能服务抽象实现成一个个小服务进行分布式交互
特点：
1)将系统服务层完全独立出来，并将业务服务抽象实现为一个一个的微服务。
2)微服务遵循单一原则。
3)微服务之间交互采用RESTful等轻量协议通信传输。
如Spring Cloud这种全家桶就是微服务架构的一个具体实现的技术框架。
优点：
1)业务服务拆分粒度更细，有利于资源重复利用，提高开发效率。
2)可更加灵活为每个服务制定不容优化方案，提高系统可维护性。
3)微服务架构采用去中心化思想，服务之间采用RESTful等轻量协议通信交互比ESB更轻量。
4)适用于复杂的互联网中大型项目，项目版本迭代周期更短。
5）各服务可采用不同技术栈实现。
缺点：
1)微服务拆分过多使服务治理成本高，系统维护成本高。
2)系统开发的技术成本高如服务熔断降级、流控、分布式事务等，对团队开发挑战大。
5：Service Mesh架构
构件粒度：面向业务功能服务和非功能服务（即系统控制服务）的彻底解耦拆分
构件交互模式：业务功能服务和非业务功能两个不同解耦拆分并实现交互
他的思想强调业务逻辑与服务治理逻辑的分层及解耦，在业务逻辑和基础实施服务治理间划分出清晰的边界。Service Mesh架构下，服务间通信通过网格进行代理，所有架构模式下解耦和复用最彻底的，不仅强调业务逻辑的解耦和复用，更强调基础设施的解耦和复用。他的本质微服务架构下服务治理平台，包含服务治理的所有方面，比如Spring Cloud这种全家桶也能实现服务治理，但是它的实现与业务逻辑耦合在一起，部署、运维同时耦合了微服务本身的操作，这样带来开发人员开发、测试、回归、发布的都是巨大重复工作。Service Mesh通过将与业务逻辑无关的服务治理逻辑下沉到基础设施，让业务开发人员与基础技术开发人员关注点分离，各司其职，大大提升了研发效能。业务开发人员可以更关注对业务的理解、建模，他们可以集中精力在业务开发实现上。目前比较流行的Service Mesh架构实现基于云原生的Istio。
文/老猿，写代码写诗写职场的程序猿大叔，倾力原创简单实用的硬干货，转载此文请联系老猿。
