下载掌阅APP，畅读海量书库
立即打开
随着软件项目或产品用户数量的增加、业务功能复杂程度的提高以及业务之间关联程度的增加，开发模式、技术架构等都发生了非常大的变化，软件系统架构也经历了一系列的演变过程，我们来看一下系统架构演变过程中一些典型特点。
（1）所有功能集中在一个项目中。
（2）所有功能都要生成war包，部署到服务器。
（3）通过集群（session共享集群）来提高服务器的性能。
优点：
· 项目架构简单，前期开发的成本低，周期短，适合小型项目。
缺点：
· 全部的功能都集中在一个项目中完成，这对于大型项目来说，开发难度高，不易开发、扩展和维护。
当访问量逐渐增大时，单一应用无法满足需求，此时为了应对更高的并发和业务需求，我们根据业务功能对系统进行拆分，称为垂直架构，其特点是：
（1）以单体架构为单位进行系统的划分，划分成一个个系统。
（2）项目与项目之间存在数据冗余，耦合度高。
（3）项目以接口调用为主，存在数据同步问题。
优点：
· 系统拆分实现了流量分担，解决了并发问题。
· 可以针对不同模块进行优化。
· 方便水平扩展，负载均衡，容错率提高。
缺点：
· 服务之间相互调用，如果某个服务的端口或者IP地址发生改变，调用的系统需要手动改变。
· 搭建集群之后，实现负载均衡就比较复杂。
当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速地响应多变的市场需求，这就是SOA服务架构。面向服务的架构是一种软件体系结构，应用程序的不同组件通过网络上的通信协议，向其他组件提供服务。通信可以是简单的数据传递，也可以是两个或多个服务彼此协调连接。这些独特的服务执行一些小功能，例如，验证付款、创建用户账户或提供社交登录等。
面向服务的架构不太关心如何以模块化方式来构建应用程序，更多的关注点在于如何通过整合分布式、单独维护和部署的软件组件来组成应用程序。通过技术和标准的实现，使得组件能够更容易地通过网络（尤其是IP网络）进行通信和协作。
SOA架构中有两个主要角色：服务提供者（Provider）和服务使用者（Consumer）。软件代理可以扮演这两个角色。Consumer层是用户（人、应用程序或第三方的其他组件）与SOA交互的端点，Provider层则由SOA架构内的所有服务构成，其特点是：
（1）基于SOA服务思想进行功能的抽取（解决重复代码问题），以服务为中心来管理项目。
（2）各个系统之间要进行调用，所以出现ESB来管理项目（可以使用各种技术实现：RPC、Webservice等）。
（3）ESB作为系统与系统之间桥梁，很难进行统一管理。
优点：
· 重复代码进行了抽取，提高了开发效率，提高了系统的可维护性。
· 可以针对某个系统进行扩展，做集群更容易。
· 采用ESB来管理服务组件，有利于降低企业开发项目的难度。
缺点：
· 系统与服务的界限模糊，不利于设计。
· ESB作为系统与系统之间的桥梁，没有统一标准，种类很多，不利于维护。
微服务架构在某种程度上是面向服务的架构SOA继续发展的下一阶段，可以认为是细粒度的SOA。基本上，这种架构类型是开发软件、网络或移动应用程序作为独立服务套件（又称微服务）的一种特殊方式。这些服务的创建仅限于一个特定的业务功能，如用户管理、用户角色、购物车、搜索引擎、社交媒体登录等。此外，它们是完全独立的，也就是说它们可以写入不同的编程语言，并使用不同的数据库。集中式服务管理几乎不存在，微服务使用轻量级HTTP、REST或Thrift API进行通信，其特点是：
（1）把系统的服务层完全独立出来，有利于资源的重复利用，可提高开发效率。
（2）微服务遵守单一原则。
（3）微服务与微服务之间的调用使用RESTful轻量级调用。
优点：
· 微服务拆分更细，有利于资源的重复利用，可提高开发效率。
· 可以更加精准地针对某个服务做方案。
· 微服务去中心化，使用RESTful轻量级通信协议比使用ESB企业服务总线更容易维护。
· 适应市场更容易，产品迭代周期更短。
缺点：
· 微服务数量多，服务治理成本高，不利于系统维护。
· 分布式系统架构且是微服务架构，技术成本高（容错、分布式事务等），对团队挑战高。
了解了各种架构的特点，就可以在项目面临架构选择的时候合理考虑采用哪种更适合。针对不同的业务特征的系统，会有各自的考虑侧重点，比如淘宝这类网站要解决的是海量商品搜索、下单、支付等问题；腾讯要解决的是数亿级别用户的实时消息传输；百度所要解决的是海量数据的搜索。每一类的业务都有自己不同的系统架构。微服务架构虽然有很多优点，但并不是解决所有问题的万金油，一般需要满足具有自己特点的使用场景，比如：团队规模较大，人数较多；业务复杂度高，子模块数量较多；项目需要长期迭代开发和维护等。