系统架构的演变

系统架构的演变

一，集中式架构
当网站流量很小时，只需要一个应用将所有的功能部署到一起，以减少部署的节点和成本。
优点：

• 系统开发速度快
• 维护成本低
• 适用于并发较低的系统

缺点：

• 代码耦合度高，后期维护困难
• 无法针对不同的模块进行针对性优化
• 无法水平扩展
• 单点容错率低，并发能力差

二，垂直架构
当访问量逐渐增大，单一应用无法满足需求，为应对更高的并发和业务需求，根据业务功能对系统进行拆分。

优点：

• 系统拆分实现了流量分担，解决了并发问题
• 可以针对不同的模块进行优化
• 方便水平扩展，负载均衡，容错率高

缺点：

• 系统间相互独立，会有很多重复开发工作，影响开发效率

三，分布式服务
当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心。

优点：

• 将基础服务进行抽取，系统间相互调用，提高了代码的复用性和开发效率

缺点：

• 系统间耦合读变高，调用关系错综复杂，难以维护

四，面向服务架构（SOA）
SOA：面向服务架构，它是一种设计方法，其中包含多个服务，服务之间通过相互依赖最终提供一系列功能。一个服务通常以独立的形式存在操作系统中。各个服务之间通过网络相互调用。
SOA结构图：

ESB企业服务总线，简单的说ESB就是一根管道，用来连接各个服务节点，为了继承不同系统不同协议的服务，ESB做了消息的转化解释和路由工作，让不同的服务互联互通。
缺点：

• 每个供应商提供的ESB产品有偏差，自身实现较为复杂，应用服务粒度较大，ESB继承整合所有服务和协议，数据转换使得运维、测试、部署困难。所有服务都通过一个通路通信，直接降低了通信速度。

五，微服务架构
微服务架构是使用一套小服务来开发单个应用的方式或途径，每个微服务基于单一业务能力构建，运行在自己的进程中，使用轻量级机制通信，通常是HTTP、API，能够通过自动化部署机制来独立部署。
微服务结构图：

特点：

• 单一职责：微服务中每个服务都对应唯一的业务能力，做到单一职责
• 微：微服务拆分力度很小，列入一个用户管理就可以作为一个微服务。
• 面向服务：每个服务都要对外暴露Rest风格的API。
• 自治：服务间互相独立，互不干扰。

SOA与微服务的差别：

RPC：基于socket,速度快，效率高；Dubbo

HTTP:基于TCP，封装比较臃肿。对服务和调用方没有任何技术、语言限定，自由灵活；SpringCloud