文末抽奖（欢迎评论）--微服务SpringCloud集群项目（一）：谈一谈微服务

Sunny_Chen
2,562 阅读12分钟

本文已申请到掘金周边礼物，掘金徽章*2 用于评论区抽奖，通过评论的方式参与 详情看这里

📖前言

文末抽奖：欢迎评论区留言讨论，热评前两名将奖励掘金周边礼品赠送~

这是我的一片老文轻喷，欢迎拿当下和前不久进行比较讨论~留个问题：大家觉得会是 Dubbo取代SpringCloud 还是会有什么有趣的今后呢？

余光中说过这样一句话：

下次你路过，人间已无我。

把人与人之间的关系，体现的淋漓尽致。

人这一生，有几辈子可以活？满打满算不过几十年，加在一起不过三万多天，真的不长。

这一路走来，有多少人和我们擦肩，然后彻底的留在记忆，明明就是同一个城市，可却几十年不曾相遇。

最让人惋惜的，不是一开始就陌生，而是明明很熟悉，慢慢的变成了陌生人。

通讯录里的名字，布满了灰尘，朋友圈里的动态，从没翻看过。

微服务SpringCloud项目

博主想从今天开始编写关于《微服务SpringCloud项目》编写一系列文章--本篇是有一定历史的老文了，将会持续稳定的更新（或许每篇的间隔会比较久希望大家有点耐心），感兴趣的小伙伴记得加关注哦！

关于微服务

这是我在19年的一篇文章，大家看看好了，既然要搞肯定要相对稳定比较新的版本来做~

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的特点

  1. 系统集成：站在系统的角度，解决企业系统间的通信问 题，把原先散乱、无规划的系统间的网状结构，梳理成 规整、可治理的系统间星形结构，这一步往往需要引入 一些产品，比如 ESB、以及技术规范、服务管理规范； 这一步解决的核心问题是【有序】

  2. 系统的服务化：站在功能的角度，把业务逻辑抽象成 可复用、可组装的服务，通过服务的编排实现业务的 快速再生，目的：把原先固有的业务功能转变为通用 的业务服务，实现业务逻辑的快速复用；这一步解决 的核心问题是【复用】

  3. 业务的服务化：站在企业的角度，把企业职能抽象成 可复用、可组装的服务；把原先职能化的企业架构转变为服务化的企业架构，进一步提升企业的对外服务能力；“前面两步都是从技术层面来解决系统调用、系统功能复用的问题”。第三步，则是以业务驱动把一个业务单元封装成一项服务。这一步解决的核心问题是【高效】

微服务的特点

  1. 通过服务实现组件化

        开发者不再需要协调其它服务部署对本服务的影响。

  2. 按业务能力来划分服务和开发团队

         开发者可以自由选择开发技术，提供 API 服务

  3. 去中心化

         每个微服务有自己私有的数据库持久化业务数据
     每个微服务只能访问自己的数据库，而不能访问其它服务的数据库
     某些业务场景下，需要在一个事务中更新多个数据库。
     这种情况也不能直接访问其它微服务的数据库，而是通过对于微服务进行操作。
     数据的去中心化，进一步降低了微服务之间的耦合度，不同服务可以采用不同的数据库技术（SQL、NoSQL等）。
     在复杂的业务场景下，如果包含多个微服务，通常在客户端或者中间层（网关）处理。

  4. 基础设施自动化（devops、自动化部署）

    Java EE部署架构，通过展现层打包WARs，业务层划分到JARs最后部署为EAR一个大包，
而微服务则打开了这个黑盒子，把应用拆分成为一个一个的单个服务，应用Docker技术，不依赖任何服务器和数据模型，
是一个全栈应用，可以通过自动化方式独立部署，每个服务运行在自己的进程中，
通过轻量的通讯机制联系，经常是基于HTTP资源API，这些服务基于业务能力构建，
能实现集中化管理（因为服务太多啦，不集中管理就无法DevOps啦）。

再画一个表格（用在当下不知道落伍不落伍）：

项目SOASpringCloud
组件大小大块业务逻辑单独任务或小块业务逻辑
耦合通常松耦合总是松耦合
公司架构任何类型小型、专注于功能交叉团队
管理着重中央管理着重分散管理
目标确保应用能够交互操作执行新功能、快速拓展开发团队

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 都提供了哪些支持。

项目框架DubboSpringCloudDubbo SpringCloud 和 SPringCloudAlibaba 后面在写文聊吧
社区活跃度Dubbo（从GitHub上来看活跃度较低）SpringCloud（从GitHub上来看活跃度极高）
更新频率很低高速迭代的阶段
架构完整度低高
服务注册中心ZookeeperSpring Cloud Netflix Eureka
服务调用方式RPCREST 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这个大将的支持，开发起来非常的便利和简单。

  • Dubbo 确实很牛逼，但是 Spring Cloud 是站在近些年技术发展之上进行开发，因此更具技术代表性。使用 Dubbo 构建的微服务架构就像组装电脑，各环节我们的选择自由度很高，但是最终结果很有可能因为一条内存质量不行就点不亮了，但是如果你是一名高手，那这些都不是问题；而 Spring Cloud 就像 品牌机，在 Spring Source 的整合下，做了大量的兼容性测试，保证了机器拥有更高的稳定性，但是如果要在使用非原装组件外的东西，就需要对其基础有足够的了解。

从之前的SSM来写代码走到 Springboot+maven+mybatis（SpringDataJpa、hibernate），从 sql server 到 MySql（博主一直在用MySql），再到 Redis 和 Mongodb 来做缓存处理。从单数据库到数据库集群（Mycat+mysql）读写分离分库分表主从复制，再到 Redis的集群Cluster模式的高扩展性，最后进阶使用SpringCloud微服务架构开发集群项目 。

✨关于抽奖

  • 评论区抽奖要求：

    • 截止到 9月10日，评论区超过 10 人互动（不含作者本人），将按文首所言送出——超级无敌巨好看可爱的掘金徽章 2 枚。

  • 礼物寄送

    • 最迟于 9 月 13 日中午 12 点前，我会将 评论区获奖用户 的收件信息填入掘金回收问卷
    • 掘金运营同学（一群可爱的小姐姐哈哈哈~）预计将于当周内完成所有礼物邮寄

  • 核实信息：

    • 刷评论（比如「踩踩」「支持」「欢迎回踩」等或类似评论）不可参与抽奖，评论区需以讨论文章内容为主谢谢合作

🎉总结一下

  • 后续文我会用 SpringCloudAlibaba 结合 Dubbo 我相信 SpringCloudAlibaba 会是一个很牛逼的东西，就后面慢慢讲解吧。

  • 当然我给自己挖的坑也会慢慢填，大家不要嫌弃可能更新会相对较慢，但绝对保证质量。

  • 更多参考精彩博文请看这里：《陈永佳的博客》

  • 喜欢博主的小伙伴可以加个关注、点个赞哦，持续更新嘿嘿！

avatar
文章
阅读
粉丝