SpringCloud学习笔记一：微服务架构的理念入门

互联网架构发展

个人觉得互联网架构的发展可以从两个层面来看。
一是业务层面，二是系统的技术架构层面和部署方式。
就比如单体应用到分布式应用上不光改进了业务层面（将主业务分割成一个个子业务，）也改进了系统的技术架构层面（部署到多台机器上）

单体应用

在早期互联网发展中，采用单体应用的开发模式。一个程序员可能参与到各个功能模块的开发之中。开发完成之后合并代码统一编译打包上线，这时生产环境的某一个模块发生错误。改完bug之后就要所有模块再次统一打包上线。影响到其他模块的功能。

集群

单体应用不止模块代码模块之间的耦合度高，随着互联网发展的深入和业务量的增长，单台服务器和单个程序已很难响应巨大的访问流量。这时集群模式就登上了舞台。不过集群模式也相对容易，简单来说就是把一个单体程序同时部署在多台服务器产生一堆节点，然后再用诸如Nginx这类代理工具以一定的规则(例如对IP地址哈希)把请求分散到不同的节点。

分布式和soa

在《分布式系统概念与设计》一书中，对分布式系统做了如下定义：分布式系统是一个硬件或软件组件分布在不同的网络计算机上，彼此之间仅仅通过消息传递进行通信和协调的系统。简单来说就是一群独立计算机集合共同对外提供服务，但是对于系统的用户来说，就像是一台计算机在提供服务一样。其实就是把之前单体应用拆分开来。把主业务拆分成多个子业务并分别部署
SOA:（Service Oriented Architecture） 面向服务的架构。把工程拆分成服务层、表现层两个工程，服务层中包含业务逻辑，只需要对外提供服务即可。表现层只需处理和页面的交互，业务逻辑都是调用服务层的服务来实现。
架构发展到这里其实已经非常完善了，但是在分布式和soa系统中同样有一个问题,虽然 这个时候其实已经将一个功能分开成一个个服务来单独部署了。但是一些功能服务中依然包含一些通用公用代码无法去掉增加了开发的工作量。

微服务

微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相协作（通常是基于HTTP协议的RESTful API）。每个服务都围绕着具体业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。
简单来说就是把一个服务拆分成多个子服务并且还可以拆分成颗粒度更小的更微小的服务
微服务的定义：把一个服务拆分成多个子服务并且还可以拆分成颗粒度更小的更微小的服务，这些服务可以放在同一个服务器上，也可以放在不同的服务器上。
分布式的定义：把一个服务拆分成多个子服务，分别放在不同的服务器上。
分布式一定是微服务，微服务不一定是分布式。