学习到Spring Cloud这部分的内容，才发现慢慢的，我已经稍微接近了架构的范畴。或者本身学习spring框架本身，就是属于进入了架构的内容。今天为了总结关于系统架构开发，特意做的小笔记。

1、系统架构的开发演变

计算机技术就是随着互联网的发展而发展起来，包括系统架构也是如此不断地升级迭代。

1.1 集中式架构

在一开始网站流量很小的时候，只需要一个应用就可以将所有的功能部署在一起以减少部署的节点个数和方便管理的成本。

额，比如说我的个人的记账或者是个人的博客系统开发应该就是典型的集中式架构了。这里举一个大家都会选择做的商品购物网站系统。(补充：最下面是数据库的模型图)

首先优点就是系统开发很快，维护成本降低并且适用于要求低的系统。

当然缺点明显：

集中式管理对于项目的耦合度过高，后期维护比较困难。

无法针对不同的模块进行优化。

无法进行水平的扩展—即项目某个功能的优化

并发能力较差

1.2 垂直拆分

然后渐渐地，你的个人博客或者个人商品管理系统访问量逐渐增大，这个时候为了应对更高的并发和业务要求，就要根据业务功能对系统进行拆分。

具体开发估计也不一定会像我这样的内容拆分进行垂直开发，不过相对于集中式架构很明显我们是单独的拎出来了。优点很明显：

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

缺点在犹豫独立性好像又相对集中式大大增强。这样对于重复开发工作率就会大大增加。

1.3 分布式服务

当发现垂直应用越来越多，好像应用之间的交互就会不可避免了，并且每个模块之间并没有主次之分(比如说用户可能更多会使用商品主要内容的浏览而非权限&用户管理)。

这个时候就将核心业务抽取出来作为独立的服务，形成整个项目中的服务中心。前端应用能够更加快速的响应多变的市场需求。所以基于垂直拆分的缺陷，用于提高整合能力的分布式调用就是关键。

优点在于将基础服务进行了抽取，使得系统间能够相互调用提高了代码复用和开发效率。缺点在于系统的调用错综复杂，变得难以维护。

1.4 服务治理

SOA服务治理就是面向服务的架构。这个时候就有这种类似微服务相关的概念了。

它是一种设计方法，其中包括多种服务，服务之间通过相互依赖最终提供一系列的功能。一个服务通常以独立的形式存在于操作系统中。各个服务之间通过网络来调用。

这就有点像腾讯集“QQ音乐、酷狗和酷我音乐”组成的腾讯音乐市场一样，腾讯通过购买并获得的音乐版权通过连接服务，就可以在这三家音乐软件进行使用。个人形象理解如有误请谅解。

ESB就像是一根管道，用来里连接各个服务节点。为了集成不同系统，不同协议的服务，即做了消息的转化解释和路有工作让不同的服务互联互通。

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

1.5 微服务

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

这些服务可以使用不同的 编程语言实现，以及不同数据存储技术，并保持最低限度的集中式管理。

API Gateway网关是一个服务器，是系统的唯一入口。网关提供RESTful/HTTP的方式访问服务。而服务端通过服务注册中心进行服务注册和管理。

微服务特点：

单一职责：微服务中每一个服务都对应唯一的业务能力，做到单一职责

面向服务：面向服务是说每个服务都要对外暴露服务接口API。并不关心服务的技术实现，做到与平台和语言无关，也不限定用什么技术实现，只要提供REST的接口即可。

自治：自治是说服务间互相独立，互不干扰

• 团队独立：每个服务都是一个独立的开发团队。
• 技术独立：因为是面向服务，提供REST接口，使用什么技术没有别人干涉
• 前后端分离：采用前后端分离开发，提供统一REST接口，后端不用再为PC、移动段开发不同接口
• 数据库分离：每个服务都使用自己的数据源

2、远程调用方式

对于面向服务的架构，SOA和微服务都是面临着服务的远程调用。接下来就说一下远程调用方式。

常见的远程调用方式有以下几种：

• RPC：Remote Procedure Call远程过程调用，类似的还有RMI。自定义数据格式，基于原生TCP通信，速度快，效率高。早期的Web Service，现在热门的Dubbo，都是RPC的典型。
• HTTP：HTTP其实是一种网络传输协议，基于TCP，规定了数据传输的格式。现在客户端浏览器与服务端通信基本都是采用HTTP协议。也可以用来进行远程服务调用。缺点是消息封装臃肿。现在热门的REST风格，就可以通过HTTP协议来实现。

这两个方式并没有哪一个好或者不好，当然要看具体情况具体分析。

2.1 RPC

RPC是一个计算机通信协议。 该协议允许运行于一台计算机的程 序调用另一台计算机的子程序，而程序员无需额外地为这个交互作用编程。说得通俗一点就是：A计算机提供一个服务，B计算机可以像调用本地服务那样调用A计算机的服务。

RPC的机制是根据语言的API来定义的，而不是根据基于网络的应用来定义的。如果项目全部采用Java技术栈，那么使用Dubbo作为微服务架构是一个不错的选择。

2.2 HTTP

HTTP就更加熟悉了，它是一个网络传输协议，基于TCP，工作在应用层，规定了数据传输的格式。现在客户端浏览器与服务端通 信基本都是采用HTTP协议，也可以用来进行远程服务调用。

如果项目的技术栈多样化，而且更青睐Spring家族，那么Spring Cloud搭建微服务是最好的选择。会选择 Spring Cloud套件，因此会使用HTTP方式来实现服务间调用。

总结

基于前面两个内容的学习，已经很好的引出了spring cloud的概念，后续会对spring cloud的相关内容进行详细的介绍。谢谢大家的阅读。