实操搭建微服务架构的三个新体会

最近的疫情有蔓延趋势，响应号召，不到处乱跑，在家呆着，借放假的时机，继续学习新知识，补充能量。祝大家鼠年吉祥，心想事成！

近期与几个互联网大厂有一些项目合作，提到了微服务在项目中的实际应用，这几天借助Dubbo的分布式服务框架搭建了一个测试环境，通过实践发现了几个与理论学习中不同的体会，现分享。

为什么需要用到分布式管理框架

一、单体式、垂直架构不能适应大型业务的变化、壮大需要：我们在云计算项目中，经常看到用户的应用都是单体架构，例如需要64vCPU、128M内存，10T硬盘，这类应用往往都是单体式的架构。软件商将所有的应用组件全部打包进一个文件中，称为单体架构，所有的服务都通过这一个文件对提供服务，如果软件需要变更、需要升级，会中断业务，非容易出错。

为了解决以上的问题，为不同的功能同不同的服务器承载，中间通过网络互通信信息，称为垂直架构。例如拆分为订单、快递、商品等模块。但不同的模块间仍存在重新的开发工作量，典型是用户的认证模块，其实是共同的需要。

二、分布式的架构将不同的软件模块彻底解耦。为了解决以上的问题，我们将公共的模块拿出来，作为公共功能供各模块调用，形成了更复杂的网状业务调度关系。如果我们需要对某功能进行扩容、升级，我们只需要变化其中一个模块就可以了。

三、分布式管理架构让业务管理更轻松。一个复杂的业务调度关系如果缺 少管理手段，将非常痛苦，例如：同一个业务的负载均衡、灰度业务发布等很难实现。我们非常需要一套管理框架帮助我们管理成千、上万的微服务业务模块的调度关系。

Dubbo具有三大重要特性

一、实现不同业务之间调用容易。

有了Dubbo框架，消费者调用服务者提供的服务，只需要知道服务者发布的服务名即可，不需要在程序中配置服务者的ip地址等信息。

如下图，有一个服务名为com.atguigu.gmall.service.UserService，消费者拿到这个服务名即可调用其中的方法。

该服务目前由192.168.101.2这个服务器在20884这个端口提供服务，消费者调用该服务后，由Dubbo将详细的服务器信息返回消费者。

通过Dubbo的注册中心，服务提供者、消费者不再保存各服务的复杂配置信息，仅需要知道服务名即可互通信息。

二、实现不同业务的负载均衡容易。

如果某业务的被调用量非常高，我们可以通过多台服务器对外提供服务，例如用户的认证模块。

例如下图，同一个服务，由三台服务器对外提供服务。（注：因是实验环境，我在同一台服务器的三个不同端口对外模拟三台服务器提供服务）

Dubbo将根据不同的负载调度策略对外分配不同的服务器。例如下图，192.168.101.2:20084这台服务器的权重为400，同时将承担更多的业务调度量。

三、实现同一个业务的灰度发布容易。

如果我们希望根据自己的业务需要来指定对外提供的服务器，我们可以使用“路由规则"，根据不同的策略选择服务器。

例如下图，对192.168.0.1这个消费者指向它访问getUserAddressList方法时，直接指向192.168.101.2这个服务提供者。这个功能的主要应用场景有灰度发布，如果我们有一些新功能只面向特定区域的用户提供服务，我们可以使用该功能。

微服务小结

这几年随着Docker的兴起，业务可以随着负载随时增加扩展服务器，通过K8s扩展出的Docker容器与微服务架构进行联动。微服务架构是面向大型业务应用系统的趋势，可以大大减少人工管理的难度、提高管理的粗细度。

如果有兴趣，建议也可以通过Eclipse+Dubbo搭建测试环境，实践有助于增强对理论的理解，方便在项目中的实战应用。