开启掘金成长之旅！这是我参与「掘金日新计划 · 12 月更文挑战」的第6天，点击查看活动详情

springcloud的简介与优势

随着业务越来越庞大，项目开发由曾经的单项目开发转到了微服务的开发趋势。

所谓微服务的开发就是将原本庞大的单体业务转变为多个微小的，部分的，微服务来解决业务的问题。

而微服务

微服务体积小，复杂度低：一个微服务通常只提供单个业务功能的服务，即一个微服务只专注于做好一件事，因此微服务通常代码较少，体积较小，复杂度也较低。

单体项目的劣势

• 随着业务复杂度的提高，单体应用（采用单体架构的应用程序）的代码量也越来越大，导致代码的可读性、可维护性以及扩展性下降。
• 随着用户越来越多，程序所承受的并发越来越高，而单体应用处理高并发的能力有限。
• 单体应用将所有的业务都集中在同一个工程中，修改或增加业务都可能会对其他业务造成一定的影响，导致测试难度增加。

正是这些问题，我们引入了微服务的概念。

几种常见的微服务框架

• Spring Cloud
• Dropwizard
• Restlet
• Spark
• Dubbo

今日文章的主要内容-----nacos

在讲述主角之前，我们先来引入服务治理的概念及解决的一些问题。

服务治理

在没有引入服务治理模块之前，服务之间的通信是通过服务间直接发起调用来实现的。

比如，前端在填写报名表的时候，我们可能会向后端传输数据，后端编写好了服务端并运行在服务器的某一个端口上，比如运行在xxx.xxx.xx.x:8080上面，调用的时候可能会以硬编码的形式去调用写死的接口。

然而，各个微服务实例为了满足高可用的需求，肯定会搭建集群，此时的调用链路就会变成复杂的情况图了。

如果微服务架构中独立的服务较少，可以通过在硬编码的方式对服务名称、IP、端口号进行静态配置，进而完成对服务的调用。

这时候就会要求开发者们手动维护各个服务的实例，去做一个清单来列举。

但是随着业务的发展，系统功能越来越复杂，对应的微服务实例也在不断增多。如果系统中的服务有成百上千个，手动配置各个服务的实例清单会变得越来越复杂，这个时候再使用硬编码配置的方式就非常愚蠢了。当集群规模发生改变、服务实例的增加和删减、服务命名发生修改、服务实例部署的地址或者端口发生改变，维护起来很麻烦，出错的几率也会大大增加。而且维护这种硬编码的配置内容需要消耗太多的开发资源。

即便是使用Nginx去做一个反向代理，也会出现无法直连的问题。

解决

这里我们引入我们的解决方案-----Nacos

Navos的下载

Nacos 快速开始

官网链接如上

我们如何下载呢？

首先我们要有jdk环境

jdk的配置我们就跳过了

值得一提的是

我们电脑里还需要有Maven环境

Maven的环境配置也很简单，新建一个Maven的HOME目录的变量，然后编辑Path，

配置完我们可以检查一下

打开cmd

输入mvn -v

检查无误后

git clone git@github.com:alibaba/nacos.git

我比较喜欢采用ssh去clone

个人认为比https有很多优势。

clone完毕后

我们cd 到 Nacos

mvn -Prelease-nacos -Dmaven.test.skip=true clean install -U

等待一段时间

输入

ls -al distribution/target/

我们可以找到distribution/target/下的nacos-server-2.2.0-BETA文件夹

然后进去

分别通过startup.cmd和shutdown.cmd来启动关闭