slb配置详解

我们一起来快速认识一下，负载均衡——SLB。负载均衡SLB是将访问流量根据转发策略分发到后端多台云服务器（ECS实例）的流量分发控制服务。包含两种含义：一是通过流量分发，扩展应用系统的服务能力；二是消除单点故障，提高应用系统的可用性。



应用场景

我们具体来看一看它的使用场景。

第一个使用场景的是用于高访问量的业务。

当你的应用访问量非常大，单台的服务器已经无法承载这个访问量的时候，就可以使用负载均衡，将流量分发到不同的服务器上去。

第二个场景是横向扩张系统。

当你已经使用了负载均衡，在业务有波动时可以在后端非常方便的添加和减少ECS来调整自己应用的服务能力。

第三个应用场景是消除单点故障。

当我们在使用负载均衡时，后端有多台ECS在同时工作的。一旦其中一台ECS上的应用发生了故障，那么负载均衡会通过一个健康检查的机制来及时的发现这个故障，并且能屏蔽对这台ECS的流量转发，然后将用户的请求转发到另一台正常工作的ECS实例上。

同城的容灾

阿里云负载均衡可以实现同地域多可用区之间同地域容灾，当主可用区出现故障是，可以在短时间内切换到另一备用可用区，以恢复服务能力。同时，主可用区恢复访问时，它会自动切换到主可用区。





跨地域容灾

跨地域容灾通过云解析做智能DNS，将域名解析到不同地域的负载均衡实例地址下，以实现全局负载均衡，当某个地域出现不可用时，暂停对应解析即可实现所有用户访问不受影响。



配置负载均衡

下面我们来演示一下负载均衡该如何去配置。

首先要做好准备工作，我们需要开通一台负载均衡实例和与负载均衡同一个地域的两台ECS服务器。



创建好以后，我们就可以在负载均衡的控制台看到这样一台实例了。

接下来，我们要给这个负载均衡创建一个监听。“监听”可以简单的理解为对应后端服务器里面的一个应用，比如一个网站我们来点击监听，然后点击添加监听。





假设我们的后端服务器里面有一个http的网站前端协议端口，我们可以将前后端协议端口TCP都写成80，然后根据自己的需要来选择调度算法，其实就是流量的转发方式。



下一步是健康检查，我们可以选择TCP方式。



健康检查端口会默认的和后端服务器的端口保持一致，直接确认就好了。现在，一个监听就配置好了。

接下来要去规定这台负载均衡的后端服务器是哪些。点击后端服务器，然后点击未添加服务器，将我们刚才创建的两台服务器勾选，然后批量添加就可以了。



这里有一个权重需要大家注意一下，这里的权重就是一个比例的概念，如果两台服务器写的都是100，流量将会以1:1的方式被转发到后端的两台服务器上。

微服务是近些年被广泛提及的一个概念， 微服务架构可以理解为一个轻量级的服务治理方案， 也就是将系统的功能，通过服务的形式发布到服务器上，对服务进行组合调用，实现具体的功能，解决实际业务问题的架构风格。

微服务产生于单体应用的扩大化，随着信息化不断发展，企业对软件功能的要求越来越具体，也愈发的细致，如果通过应用程序来实现，必然是一个极其复杂而又痛苦的过程，由此诞生了微服务的概念。就是 将功能发布成服务，应用程序通过调用不同的服务来实现业务， 这种设计架构称之为微服务。

微服务架构的优点在于每个服务可以有独立的团队开发，服务之间互不干涉，保障了系统的稳定性。由于功能被拆分到更细的粒度，有效的降低了程序的复杂程度，对硬件的需求也随之降低，但是微服务也有一些不足，比如服务调用带来的系统复杂性，服务间的依赖关系也是难以管理的，如何构建合理的服务依赖是考验架构师能力的重要依据；最后，微服务架构的部署以及跟踪也是很难的。总之， 微服务架构有着自身的应用场景以及特点，了解哪些场景适合微服务比掌握微服务的具体技术更为重要， 适当的技术用在适当的场景，才能发挥合适的价值。

微服务架构是当前最流行的技术架构，主要组件有注册中心、网关、配置中心和各种微服务模块。架构灵活、易扩展、可动态扩容。

在微服务之前，系统架构经历很长时间的演变，简述如下：

1无架构

页面逻辑和业务逻辑混在一起，甚至页面直接访问数据库。

优点：因为没有太多的访问路径转换，效率是最高的；

缺点：没有分层，逻辑混乱，维护难，扩展难。

2MVC

架构

单系统，表现层、逻辑层、业务层分开，各层分工协作。

优点：逻辑清晰、分工明确、易维护。

缺点：系统集中部署，属于强耦合，某些业务模块出现异常时，会导致整个系统无法访问。

3SOA架构

面向服务的架构，多个系统分布式部署，通过消息总线进行通讯。

优点：各个系统的业务相对独立，耦合低；

缺点：消息总线负担太重，中心化太重，接口缺乏规范。

4微服务架构

一个系统，按照粒度规划，划分为很多的微服务，而每个微服务，对应一个具体的业务实现，并可拥有自己独立的数据库，整个就是微服务架构。

优点：如上，架构灵活、易扩展，在实际运营时，按需扩容，集群部署。各个微服务业务互不影响，耦合性低；

缺点：开发成本高，对部署有一定的专业性要求。

从技术而言，微服务已经是一个设计理念很成熟的架构，可满足不同层次，不同业务场景的需要，而且经过多个版本的迭代，该踩的坑也基本踩完，生态系统完整，开源组件选择多多，很有一统天下的趋势，值得尝试。

但，不要为了微服务而微服务，要根据自己实际的要求去做抉择和取舍。

比较，适合自己的，才是最好的！

微服务是近几年技术社群讨论很多的一种软件架构方式，可以说是SOA的现代版本、 时尚 版本。不过这次浪潮不是由大公司倡导的，而是由工程师们引领的。比如，它采用工程师们熟悉的RESTful接口，而不是笨重的WebService，也不需要一大堆昂贵的中间件。

那微服务为什么流行起来？按理说它们都是让软件更加模块化，使相互之间保持松耦合，从而优化系统架构。

国内流行起来的微服务架构——RestCloud

RestCloud 为了保证服务不注册中心癿高可用性，服务不注册中心通过水平扩展癿能

力允许对服务不注册中心迚行集群配置，开在网关层做了服务癿注册癿数据缓存。

Spring Cloud Eureka 是 Spring Cloud Netflix 微服务套件中癿一部分，它基于 Netflix Eureka做了二次封装。主要负责完成微服务架极中的服务治理功能。

易用性

如果你目前使用SpringBoot开发API服务则无需修改任何代码，只需引入RestCloud配置中心的jar包即可由配置中心接管所有配置，对开发人员无任何感知，如果你使用RestBoot开发平台开发API则已经是天然集成了配置中心的客户端Jar包无需任何依赖。 如果你使用php,c#开发目前RestCloud并没有提供现成的解决方案，你需要通过Rest API来接入RestCloud配置中心并自已在本地实现配置缓存管理。

稳定性

RestCloud采取全新的本地配置持久化技术，保证配置中心不会形成单点故障，因为所有的配置数据在应用则具有本地缓存和持久化技术，假定RestCloud配置中心出现故障且长时间未能恢复的情况下，应用则的程序会自动读取本地缓存配置数据 进一步假定这时应用也刚好出现故障需要重启，则本地缓存在重启后将会消失,这时应用将自动从持久层再次读取配置数据到缓存中从而恢复运行，所以RestCloud配置中心不会出现故障后影响应用的运行,RestCloud配置中心优于目前开源的大多数配置中心解决方案。

易用性

如果你目前使用SpringBoot开发API服务则无需修改任何代码，只需引入RestCloud配置中心的jar包即可由配置中心接管所有配置，对开发人员无任何感知，如果你使用RestBoot开发平台开发API则已经是天然集成了配置中心的客户端Jar包无需任何依赖。 如果你使用php,c#开发目前RestCloud并没有提供现成的解决方案，你需要通过Rest API来接入RestCloud配置中心并自已在本地实现配置缓存管理。

稳定性

RestCloud采取全新的本地配置持久化技术，保证配置中心不会形成单点故障，因为所有的配置数据在应用则具有本地缓存和持久化技术，假定RestCloud配置中心出现故障且长时间未能恢复的情况下，应用则的程序会自动读取本地缓存配置数据 进一步假定这时应用也刚好出现故障需要重启，则本地缓存在重启后将会消失,这时应用将自动从持久层再次读取配置数据到缓存中从而恢复运行，所以RestCloud配置中心不会出现故障后影响应用的运行,RestCloud配置中心优于目前开源的大多数配置中心解决方案。

网站链接：http://wwwrestcloudcn/restcloud/mycms/indexhtml

参考资料：

https://blogcsdnnet/kezi/article/details/81276727

当云服务器使用一段时间后可能会有数据盘空间不足的情况，那么升级数据盘大小之后就需要进行系统内部磁盘空间扩容操作，这边以数据盘20G升级为30G为例(针对此操作时需小心谨慎操作，操作失误将会导致数据丢失，建议先备份好数据再进行操作)：

1、卸载挂载中的数据盘：

umount /dev/sdb1

2、使用parted工具读取磁盘分区表信息；先使用 p 查看可扩容磁盘大小，再通过unit s命令定义默认使用sectors展示，获取起始位置信息：

3、创建新分区。先使用 rm + 序列号 来删除老的分区表；然后使用 mkpart 命令来创建即可，这里需要注意的是parted工具里END的值，由于一般大家都不清楚具体的扇区数量，可以使用容量来替代。

请注意以下操作步骤需要处于unit s的sectors扇区模式中操作，否则将导致数据盘扩展异常

rm 1mkpart primary ext4 2048 322G

PS：请注意查看执行完扩展指令退出后是否有显示红色线条展示的信息(Information: You may need to update /etc/fstab)，有的话可执行下 df -h 查看是否/dev/sdb1磁盘已自动挂载上了，那么此时就需要重新卸载数据盘进行后续操作，否则就会提示数据盘已挂载：

umount /dev/sdb1

4、检测磁盘是否有错误:

e2fsck -f /dev/sdb1

5、扩展数据盘大小：（如文件格式为xfs，则使用命令：xfs_growfs /dev/sdb1）

resize2fs /dev/sdb1

6、重新挂载磁盘并检查磁盘大小：

mount -a

这里涉及到一个概念，就是弹性伸缩。

俗话说计划不如变化快，特别是互联网行业，市场形势瞬息万变。

如果服务器容量规划和实际情况不符，可能会出现这样的情况：

可能雄心勃勃的开发了一个业务，对市场充满期待，买了一堆机器，上线后发现不温不火，服务器严重低负载，烧的都是钱啊。

相反可能一个创新的点子，本来没抱多大希望，上线后突然火了，请求量暴增，而此时你的服务器满负荷，采购扩容都来不及，导致业务一定时期不可用，让竞争对手抢占了先机。

所以服务器必须具备弹性伸缩的能力，一方面应对增长的用户量场景，一方面节约相应的成本。

服务器弹性伸缩的能力需要是在各个环节都要满足，包括前端的入口，负载均衡，后端的服务，底层的数据库都要有能力做到弹性伸缩。

弹性伸缩的含义就是在可以根据请求量的变化自动的计算资源容量，快速容易的增加机器和减少机器，甚至于更改机器的配置。

一般公司是很难做到这一点的，这涉及到主机的cpu,磁盘的虚拟化，对系统资源的容器化，对网络带宽的管理等等方方面面。对于一个小公司而言做这些事情代价是很高的。

所以公有云服务提供商出现了，他们就是专业做这个事情的，彻底托管屏蔽业务底层依赖的硬件和基础软件资源。从负载均衡，主机硬件资源，网络带宽，数据库，搜索引擎，安全防护一条龙服务。这样企业不用过多的考虑服务器资源方面的规划，一切资源可以随时增加和释放，非常方便。

对于初创公司，一般业务公司来说上云是个很不错的选择。目前比较成熟的云服务提供商包括：亚马逊AWS，微软Azure，阿里云，腾讯云，华为云等。

以上是我的建议，望采纳。

1、首先点击编辑虚拟机设置，点击“添加”按钮。

2、然后在打开的添加页面中，选择“硬盘”并点击“下一步”。

3、接着在打开的页面中，选择推荐的类型，继续“下一步”。

4、创建新的虚拟磁盘，选择容量大小。选择第二个，单个文件，单个文件方便以后迁移。

5、最后选择一个路径和文件磁盘名称，点击完成确认，即可完成扩容磁盘。

扩充服务器更新需要4小时。根据查询相关公开信息显示：扩充服务器更新机器需要做好系统和配置好做网站所需要的环境就能使用，但是如果是定制机时间会稍长一些，正常情况下24小时之内都会交付的，扩充服务器更新需要4小时。