聊聊微服务那些事儿——微服务介绍

什么是微服务

我认为的微服务架构是将系统中的每个服务或者功能独立成一个单独的可独立部署的应用。一般我们都是根据业务的边界来确定服务的边界,并根据单一职责原则保证每个服务都有很强的自治性。服务之间通过网络进行通信,以避免耦合。说白了微服务架构想要达到的目的和软件工程里面的解藕原则是一回事儿。

单一职责原则:把因相同原因而变化的东西聚合到一起,把因不同原因而变化的东西分离开来。

微服务的优点
1. 技术异构性。

在进行微服务化之后,每个服务都是一个单独的实体,服务间通过网络进行通信,所以每个服务都可以根据自身特点选择最适合自己的技术栈,不用向原来那样,单体庞大的项目都是用一个技术栈来实现。

2. 弹性。

在微服务架构中,如果某个服务不可用了,我们可以及时的隔离故障点,或者采取功能降级等方式避免因为一个服务的故障而影响整个系统。因为每个服务的边界都是一个壁舱,出问题之后不会影响其他服务,但是传统的架构方式,一个服务挂掉,会导致服务器的负载上升,整个系统的可用性都会变差。

3. 扩展。

传统的项目架构中,即便有一个简单的服务有性能瓶颈,我们也需要对整体进行扩展,微服务化之后我们只需要对特定的服务进行扩展就可以了。扩展变得更加容易也更加简单了。

4. 简化部署。

在传统项目架构中,即便我们要修改很简单的几行代码也需要进行一次整体部署,如果频繁的进行这样的部署,对我们系统的可用性影响很大,而且出错风险也比较大。所以为了避免这个问题,我们往往都是把需求积累到一定程度在上线,但是这样就会出现上线不及时,出错的概率一样不低因为改动的代码多了,出错概率自然就高了。但是微服务就可以很好的避免这些问题。

5. 微服务架构与组织架构相匹配。

当我们的代码库和团队,因为功能的增加而日益变得庞大的时候,对于团队管理和代码管理都是及其困难的。微服务化后,代码和团队都可以水平化管理。

######6.可组合性
一个服务可以多场合重复使用,这也是我们软件开发极力推崇的一种方式。比如我们不仅可以满足系统间的调用,还可以满足手机端,web端,可穿戴设备等等。每个服务都可以自由的组合。

6. 对可替代性的优化。

单一庞大的系统,特别是遗留很久的系统,很少有同事愿意触碰,更别说修改了,因为里面全是坑。但是微服务化之后,因为功能和结构都是单一职责的,代码量也少很多,所以优化和修改起来都相对简单。

微服务需要的基本组件

说了这么多微服务架构的好处,很多同学可能已经迫不及待的跃跃欲试了。为了满足你们急切的心情,我来说说大家比较关心的,一个合格的微服务架构都需要哪些组件来支撑。
首先你需要一个注册中心用来注册所有的服务,其次你可能还需要一个服务网关,负责对流量控制,用户认证等。然后我们还需要一个服务熔断器,对服务进行隔离降级。还需要负载均衡,分布式日志等。对了我们还需要一个重要的组件,就是对服务进行服务化的框架。
除了这些我们还需要一套PASS平台,来部署所有的服务。嗯,差不多把这些都搞定就可以运维你的微服务框架了。

慎重选择微服务–没有银弹

说了这么多我想根据自己的经验来说说对微服务框架的认识。我的建议就是慎重选择微服务框架。你要进行微服务架构改造至少要根据以下这么几点进行考量:

  1. 是否有完整的运维平台。
  2. 项目是否有必要进行微服务改造。
  3. 团队规模是否支撑你去搞微服务。

我之所以这么说是因为微服务不是免费的午餐,更不是银弹。你需要面对所有分布式系统需要面对的所有问题。另外部署运维也是你需要考虑的一个问题。这里我举一个例子,大家设想一下,假设我们有30个服务,传统服务是打包到一个应用一起部署,假设我们部署到10台机器上,这样的话撑个几百上千个TPS是不成问题的。但是如果我们微服务化之后,至少要变成30个单体应用,这还不算注册中心,网关,熔断等等其他应用,这样我们就需要三十台机器部署,我们不可能搞单点应用,每个服务都要两到三个节点,这样一来就上百台机器了。所以这样看来,所有成本都上来了,机器的问题我们可以通过云平台来解决,现在已经不是问题了,但是接下来的其他问题呢,大家就要好好考量一下了。总之不要一言不合就飙车。

微服务框架–SpringCloud

正如前面所说,没有一条通用准则来支持我们如何为服务化,目前也没有一款通用的微服务框架。其实仔细想想,这也是有原因的。微服务用到的这些概念和组件都是大家不断在实践中总结出来的。随着业务增加,业务复杂度增加,我们的架构在不断的变化,当我们需要一个网关的时候,就针对自己公司的业务和场景自己开发一个,当我们需要一个注册中心的时候,我们也自己开发一个。随着时间的推移,我们的项目慢慢就变成微服务的样子了。但是这些根据自己公司业务场景开发的组件不具备太多通用性,而且能达到开源条件的也比较少,所以到目前为止还没有一个通用的框架出现。就在大家都想微服务化又缺少通用标准框架的时候,SpringCloud就站了出来,其实他也是站在了巨人的肩膀上,这个巨人就是Netflix。这家公司开源了,eureka,zuul,robbin,hydrix四个主要的项目,SpringCloud把这个四个项目基于自己的SpringBoot有机的整合到了一起,完成了注册中心,服务注册发现,负载均衡,网关,熔断等主要功能。这给很多没有太多技术储备和精力的团队提供了一个很好的选择去专心的搞自己的服务化。

总结

上面说了那么多,是我自己这段时间搞微服务化的一些心得,说的不一定对,但确实是经验之谈,总之希望大家要慎重选择微服务,看看自己的项目是否确实需要进行架构升级,是否真的有必要选择微服务。接下来我会简单的分析一下zuul的源代码,跟大家分享一下zuul网关的实现原理。

-------------本文结束-------------
坚持原创技术分享,您的支持将鼓励我继续创作!
0%