微服务SpringCloud集群项目
博主想从今天开始编写关于《微服务SpringCloud集群项目》编写的一系列文章，将会持续稳定的更新，感兴趣的小伙伴记得加关注哦！
关于微服务
目前，Spring Cloud在国内的知名度并不高，在前阵子的求职过程中，与一些互联网公司的架构师、面试官或者CTO在交流时，有些甚至还不知道该项目的存在。可能这也与国内阿里巴巴开源服务治理框架Dubbo有一定的关系，除了Dubbo本身较为完善的中文文档之外，不少科技公司的架构师均出自阿里系，所以就目前情况看，短期国内还是Dubbo的天下。
那么第一次实施微服务架构时，我们应该选择哪个基础框架更好呢？
以下内容均为作者个人观点，知识面有限，如有不对，纯属正常，不喜勿喷。
浅谈对微服务框架的认知
在博主之前的理解中企业级SOA开发和微服务开发SpringCloud有着一定的区别。当然各位想说还有一个Dubbo，可能持续关注的伙伴会了解到，Dubbo以前是由阿里维护之间放弃过一段时间的维护，也是一个不错的框架。于2018年11月，Spring官方联合阿里巴巴宣布开源SpringCloud-Alibba项目，声称要开创符合中国国情的道路，博主也相信阿里有这个能力。当然了SpringCloud-Alibaba他的基准是谁呢？没错就是SpringCloud框架，博主从Cloud1.0用到2.0经历了Cloud一岁到两岁的变化，下面拿出一点自己的见解向大家阐述一下！
当然博主是选择了SpringCloud啦!
浅谈SOA和SpringCloud
1）SOA和SpringCloud的区别是在业务的划分上
2）Soa更注重企业业务的整合划分粒度比较粗糙
3）Soa（Service Oriented Architecture）“面向服务的架构”:他是一种设计方法，其中包含多个服务， 服务之间通过相互依赖最终提供一系列的功能。一个服务 通常以独立的形式存在与操作系统进程中。各个服务之间 通过网络调用。
4）SpringCloud则是更注重拓展性业务划分更加细粒度但是不利于管理
5）SpringCloud和Dubbo的区别总结来说SpringCloud整机，Dubbo需要自己组装。
6）微服务架构（这里指用到的SpringCloud） = 80%的SOA服务架构思想 + 100%的组件化架构思想 + 80%的领域建模思想
7）微服务是在 SOA 上做的升华，微服务架构强调的一个重点是“业务需要彻底的组件化和服务化”
8）即将原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。这些小应用之间通过服务完成交互和集成。（服务间的通信调用采用SpringCloud-Fegin组件）
SOA的特点
-
系统集成：站在系统的角度，解决企业系统间的通信问 题，把原先散乱、无规划的系统间的网状结构，梳理成
规整、可治理的系统间星形结构，这一步往往需要引入 一些产品，比如 ESB、以及技术规范、服务管理规范； 这一步解决的核心问题是【有序】 -
系统的服务化：站在功能的角度，把业务逻辑抽象成 可复用、可组装的服务，通过服务的编排实现业务的 快速再生，目的：把原先固有的业务功能转变为通用 的业务服务，实现业务逻辑的快速复用；这一步解决 的核心问题是【复用】
-
业务的服务化：站在企业的角度，把企业职能抽象成 可复用、可组装的服务；把原先职能化的企业架构转变为服务化的企业架构，进一步提升企业的对外服务能力；“前面两步都是从技术层面来解决系统调用、系统功能复用的问题”。第三步，则是以业务驱动把一个业务单元封装成一项服务。这一步解决的核心问题是【高效】
微服务的特点
-
通过服务实现组件化
开发者不再需要协调其它服务部署对本服务的影响。 -
按业务能力来划分服务和开发团队
开发者可以自由选择开发技术，提供 API 服务 -
去中心化
每个微服务有自己私有的数据库持久化业务数据 每个微服务只能访问自己的数据库，而不能访问其它服务的数据库 某些业务场景下，需要在一个事务中更新多个数据库。 这种情况也不能直接访问其它微服务的数据库，而是通过对于微服务进行操作。 数据的去中心化，进一步降低了微服务之间的耦合度，不同服务可以采用不同的数据库技术（SQL、NoSQL等）。 在复杂的业务场景下，如果包含多个微服务，通常在客户端或者中间层（网关）处理。 -
基础设施自动化（devops、自动化部署）
Java EE部署架构，通过展现层打包WARs，业务层划分到JARs最后部署为EAR一个大包， 而微服务则打开了这个黑盒子，把应用拆分成为一个一个的单个服务，应用Docker技术，不依赖任何服务器和数据模型， 是一个全栈应用，可以通过自动化方式独立部署，每个服务运行在自己的进程中， 通过轻量的通讯机制联系，经常是基于HTTP资源API，这些服务基于业务能力构建， 能实现集中化管理（因为服务太多啦，不集中管理就无法DevOps啦）。
在画一个表格：
| 项目 | SOA | SpringCloud |
|---|---|---|
| 组件大小 | 大块业务逻辑 | 单独任务或小块业务逻辑 |
| 耦合 | 通常松耦合 | 总是松耦合 |
| 公司架构 | 任何类型 | 小型、专注于功能交叉团队 |
| 管理 | 着重中央管理 | 着重分散管理 |
| 目标 | 确保应用能够交互操作 | 执行新功能、快速拓展开发团队 |
SpringCloud和Dubbo的优缺点
背景
Dubbo，是阿里巴巴服务化治理的核心框架，并被广泛应用于阿里巴巴集团的各成员站点。阿里巴巴近几年对开源社区的贡献不论在国内还是国外都是引人注目的，比如：JStorm捐赠给Apache并加入Apache基金会等，为中国互联网人争足了面子，使得阿里巴巴在国人眼里已经从电商升级为一家科技公司了。
Spring Cloud，从命名我们就可以知道，它是Spring Source的产物，Spring社区的强大背景可以说是Java企业界最有影响力的组织了，除了Spring Source之外，还有Pivotal和Netfix是其强大的后盾与技术输出。其中Netflix开源的整套微服务架构套件是Spring Cloud的核心。
小结：拿Dubbo与Netflix套件做对比，前者在国内影响力大，后者在国外影响力大，我认为在背景上可以打个平手；若要与Spring Cloud做对比，由于Spring Source的加入，在背景上，Spring Cloud略胜一筹。不过，英雄不问出处，在背景这一点上，不能作为选择框架的主要因素，当您一筹莫展的时候，可以作为参考依据。
架构完整度
在完架构整度方面或许很多人会说Spring Cloud和Dubbo的对比有点不公平，Dubbo只是实现了服务治理，而Spring Cloud下面有17个子项目（可能还会新增）分别覆盖了微服务架构下的方方面面，服务治理只是其中的一个方面，一定程度来说，Dubbo只是Spring Cloud Netflix中的一个子集。但是在选择框架上，方案完整度恰恰是一个需要重点关注的内容。
根据Martin Fowler对 微服务架构 的描述中，虽然该架构相较于单体架构有模块化解耦、可独立部署、技术多样性等诸多优点，但是由于分布式环境下解耦，也带出了不少测试与运维复杂度。
根据微服务架构在各方面的要素，看看Spring Cloud和Dubbo都提供了哪些支持。
| 项目框架 | Dubbo | SpringCloud |
|---|---|---|
| 社区活跃度 | Dubbo（从GitHub上来看活跃度较低） | SpringCloud（从GitHub上来看活跃度极高） |
| 更新频率 | 很低 | 高速迭代的阶段 |
| 架构完整度 | 低 | 高 |
| 服务注册中心 | Zookeeper | Spring Cloud Netflix Eureka |
| 服务调用方式 | RPC | REST API（Restful风格） |
| 服务网关 | 无 | Spring Cloud Netflix Zuul |
| 断路器 | 不完善 | Spring Cloud Netflix Hystrix |
| 分布式配置 | 无 | Spring Cloud Config |
| 服务跟踪 | 无 | Spring Cloud Sleuth |
| 消息总线 | 无 | Spring Cloud Bus |
| 数据流 | 无 | Spring Cloud Stream |
| 批量任务 | 无 | Spring Cloud Task |
| …… | …… | …… |
注意：
1）Dubbo由于是二进制的传输，占用带宽会更少。
2）注意SpringCloud是http协议传输，带宽会比较多，同时使用http协议一般会使用JSON报文，消耗会更大。
3）dubbo框架只是专注于服务之间的治理，如果我们需要使用配置中心、分布式跟踪这些内容都需要自己去集成，这样无形中使用dubbo的难度就会增加。
4）最牛的还是Spring Cloud几乎考虑了服务治理的方方面面，更有Spring Boot这个大将的支持，开发起来非常的便利和简单。
从之前的SSM来写代码走到Springboot+maven+mybatis（SpringDataJpa、hibernate），从sql server到MySql（博主一直在用MySql），再到Redis和Mongodb来做缓存处理。从单数据库到数据库集群（Mycat+mysql）读写分离分库分表主从复制，再到Redis的集群Cluster模式的高扩展性，最后进阶使用SpringCloud微服务架构开发集群项目，在后续文章中会陆续详细讲解。