微服务转型的三大误区,避坑指南→

标签: 微服务 转型 三大 | 发表时间:2021-04-17 02:41 | 作者:博云BoCloud
出处:http://weekly.dockone.io

通常企业的数字化转型和系统的微服务化改造很容易被放在一起讨论,这样的说法是把微服务放到了一个系统级别,也就成为了一个部门或一个团队的任务。这其实就是一个企业刚开始做微服务转型的最大误区。

微服务化转型是企业级的改造工程,而具体的落实才是系统的改造,只关注于系统的微服务化改造,难免会“守一隅而遗万方”。其实,企业微服务化转型的很多误区都是这样产生的。

01 微服务拆分的误区

博云一直为企业提供微服务拆分的咨询服务,所以经常会接到微服务拆分的项目。有些客户通常只要咨询、只要方法论、只要单个系统拆分的服务,这样的方式其实都走入了微服务建设的误区。例如,我们之前遇到一个大企的微服务化转型项目,涉及近百个业务系统的微服务改造建设。面对这么大的微服务化建设,客户的想法却很简单,计划整体改造分成三步:

第一步:找一个对微服务拆分比较专业的公司,帮忙做第一个系统的拆分工作,并学习微服务拆分的精髓。

第二步:在咨询公司的帮助下,自行拆分二三十个业务系统,作为练兵。

第三步:摆脱咨询公司的帮助,拆分改造剩下的系统。

很明显,这是为了拆分而拆分。这样的建设相当于是单体应用系统平等地置换成微服务系统的应用,导致单体应用的优势没有了,而微服务的优势也并没有体现出来。可以预见,如果继续这样建设会出现很多麻烦:

业务系统由近百个变成近千个,完全颠覆了原来的管理模式。以前只需要在资源层面、网络层面的监控运维,而对于现在服务层面的观测简直束手无策。
如果只是单系统的考虑拆分,那么微服务带来的消耗是会增加的。微服务的拆分将一个运行程序拆成了十几个,还要依赖于必要的组件,如注册中心、配置中心、网关,当然每个都需要考虑高可用,那么在资源消耗上,将增加不止一倍的消耗,这样算来,整个企业的微服务改造,将可能会多改造出一个机房来。
刚刚提到监控运维,其实运维层面还有更多的问题。上百个系统,近千个服务,再加上分布式的部署方式,将有几千个运行程序的部署和升级迭代,这绝对不容小觑。
每个改造、建设,或者变革,都会被问到一个收益的问题,投入大量的人力、物力、财力,我们想要看到的是回报,而这种方式的拆分将只有投入。

微服务化转型,或者说微服务化建设,绝对不等于微服务的拆分。微服务的拆分仅针对于某一个系统,或者几个系统,跟架构师、研发人员比较密切相关。而微服务化的建设,其实针对的是整个企业的管理、运维,并关系到所有的微服务系统的研发和运维团队。所以企业在做微服务化转型的时候,我们应该把握微服务的优势,发挥其长处,弥补其不足。

不要把微服务建设,做成了微服务批量拆分,这是要注意的第一个误区。

02 微服务化建设的误区

谈到这里似乎应该说:“不要为了微服务而微服务”,但实际上为了微服务而建设微服务也不是问题,因为云原生理念与技术的普及已经如火如荼,所以熟悉相关技术也是势在必行。

很多企业看到了微服务的前景,也开始在架构、研发等部门中,建设一些微服务治理平台或者微服务运行观测平台,但是通常这类的试验性质的项目都存在很多误区。

经常遇到的疑问:微服务是用来解决什么问题的,或者能带来什么样收益?于是企业从各方面寻找可以优化的点,比如性能优化、资源节省、运维成本、管理难度,但是这一圈下来发现收益全部是负增长。性能由于加入检测探针,增加性能消耗;资源由于增加很多治理组件,增加资源消耗;运维和管理更是几何倍增长。因此,有些企业在建设一期的微服务平台之后,迁入或者甚至都没有迁入一个微服务系统的时候,就认为微服务化没有成果,从此中断。

另外,企业在做微服务化尝试的时候,通常都会拆分一个不是很关键的业务系统,以此来测试微服务化是否真的如互联网上炒得那么火热,那么有用。然而,这个很不关键的业务系统在尝试微服务化之后,企业会轻易地得出一些 “结论”:

· 微服务的分布式似乎也没什么特别,反而带来了分布式的各种问题。

· 微服务的限流熔断一般用不着,用了还有可能影响正常业务。

· 微服务的观测也没啥用,如果不是出问题,平常根本没人看。

不仅是上面的两个理解误区,我们在做微服务类的项目时也遇到过很多比较有前瞻性的客户,但是完全按照客户的要求去建设的平台,却似乎不是很实用。等过两年之后,客户发现建设微服务还是很必要,于是总结之前的经验,觉得还是需要大厂来建设,因此只好花几倍的钱找大厂来做,而实际上再次建设可能还会遇到之前同样的问题,反而 “劳民伤财” 。其实主要原因还是没有把握住微服务的根本。

微服务解决的根本问题,总结一下其实是业务系统运行中由量变引起的一系列问题,量变引起质变,最终通过微服务的架构解决。如果业务访问量不够,那就不会用到限流熔断;如果应用服务数量不多,那就不需要统一管理和运行观测;如果服务变更不频繁,那也就不需要持续发布、灰度发布等。

微服务的优势在单一且没有业务量的系统中,完全不能发挥其长处,反而单体应用的优势更明显。这也正是微服务建设中最大的误区。

03 微服务治理平台的误区

当我们聊到微服务的时候,很多人第一印象就是拆分,一个拆成多个,这就是微服务。那么微服务治理、或者微服务运行平台,就是用来解决微服务拆成多个以后带来的问题。

具体问题有通信互访、流量保障、关系网络、运行状态、分布式事务、性能观测、故障定位、灰度发布等,很多方案都是由开源技术提供,比如微服务框架、APM 一些开源组件。

那么微服务治理平台就是开源组件的联合吗?在微服务治理中,开源组件有:

微服务框架(其实不属于组件):在治理方面主要提供微服务的通信、负载均衡等,如 SpringCloud、Dubbo;
注册中心:提供服务注册发现机制,如 Nacos、Consul 等。
服务流量限制:通常有限流、熔断、降级等功能,如使用 Hystrix 组件。
配置中心:提供统一的配置管理,尤其是分布式服务下,服务配置的统一变更,如 Apollo。
服务观测:主要是 API 维度、服务维度的性能监控,服务间关系拓扑,链路追踪、日志追踪等功能,目前使用最多的是 Skywalking。

当然还有网关、分布式任务调度、分布式事务等组件,这些组件都是微服务运行所依赖的。

那这些组件的联合就可以做到微服务的治理了吗?其实微服务治理平台,主要还是管理,以业务视角的系统、应用的管理是治理平台最大的价值。注册中心提供的是全量的服务信息,配置中心也有全量的服务配置,但全都是技术角度的依赖工具,而不是管理工具。

我们刚刚提到微服务的量变引起的管理困难,在所有的开源工具中,都不能得到解决。无论是服务列表、服务配置、服务拓扑,我们要的不是技术角度的功能实现,而是业务角度的管理观测。开源的工具不是治理,如果立项,可别踩这坑。

综上所述,微服务化转型所有的误区,其实都是因为对微服务的认识不够和对微服务的规划不明确导致的。那么微服务化建设应该从哪些方面入手才是正确的建设方向,才能保证持续的进步,才能少踩坑,少走弯路?我们将在之后的文章中为大家分享正确的微服务转型的建设思路,敬请期待。

点击 BoCloud博云了解更多解决方案

相关 [微服务 转型 三大] 推荐:

微服务转型的三大误区,避坑指南→

- - DockOne.io
通常企业的数字化转型和系统的微服务化改造很容易被放在一起讨论,这样的说法是把微服务放到了一个系统级别,也就成为了一个部门或一个团队的任务. 这其实就是一个企业刚开始做微服务转型的最大误区. 微服务化转型是企业级的改造工程,而具体的落实才是系统的改造,只关注于系统的微服务化改造,难免会“守一隅而遗万方”.

企业中台规划和IT架构微服务转型杂谈

- - 人月神话的BLOG
对于传统企业IT架构转型,中台和微服务架构规划在我头条前面的文章里面都有比较系统的整理和阐述,虽然云原生概念在2013年就提出,但是2020年可以算作是云原生的元年,同时企业IT架构转型,微服务化和逐步迁移上公有云也将是未来多年的一个技术发展趋势. 最近结合和合作伙伴,客户的沟通交流,对一些常用的问题进行整理和说明.

初识微服务

- - ITeye博客
微服务架构越来越火,有必要学习一下. 软件开发过程中碰到什么问题. 一个简单的应用会随着时间推移逐渐变大. 在每次的sprint中,开发团队都会面对新“故事”,然后开发许多新代码. 几年后,这个小而简单的应用会变成了一个巨大的怪物. 一旦你的应用变成一个又大又复杂的怪物,那开发团队肯定很痛苦. 敏捷开发和部署举步维艰,其中最主要问题就是这个应用太复杂,以至于任何单个开发者都不可能搞懂它.

谈微服务架构

- - 人月神话的BLOG
其实在前面很多文章谈到SOA,特别是系统内的SOA和组件化的时候已经很多内容和微服务架构思想是相同的,对于微服务架构,既然出现了这个新名称,那就再谈下微服务架构本身的一些特点和特性. 从这个图可以看到微服务架构的第一个重点,即业务系统本身的组件化和服务化,原来开发一个业务系统本身虽然分了组件和模块,但是本质还是紧耦合的,这关键的一个判断标准就是如果要将原有的业务系统按照模块分开部署到不同的进程里面并完成一个完整业务系统是不可能实现的.

微服务性能模式

- - 互联网 - ITeye博客
前言:基于微服务系统越来越普遍. 下面我们就来看看五种常见的特定微服务性能的挑战,以及如何应解他们. 背景:在IT界微服务架构为基础的系统越来越多, 每一个应用系统都集成了不同的组件和服务,几乎所有的特定业务应用程序都需要集成一个或更多的应用服务. 但是一个综合性系统集成不同的服务这无疑是一个巨大的挑战.

微服务与架构师

- - 乱象,印迹
因为工作的关系,最近面试了很多软件架构师,遗憾的是真正能录用的很少. 很多候选人有多年的工作经验,常见的框架也玩得很溜. 然而最擅长的是“用既定的技术方案去解决特定的问题”,如果遇到的问题没有严格对应的现成框架,就比较吃力. 这样的技能水平或许适合某些行业,但很遗憾不符合我们的要求. 软件架构师到底应该做什么,又为什么这么难做好,这都是近来的热门问题,我也一直在和朋友们讨论.

从Excel到微服务

- - 乱象,印迹
Excel很老,Excel很土,Excel一点也不sexy;微服务新,微服务很潮门,微服务很高大上. 那么,Excel和微服务有什么关系. 上个月看了篇文章,The Unbunlding of Excel. 作者认为,对于初创公司(尤其是非“纯IT”初创公司)来说,Excel几乎包办各种工作. 想做轻量级的CRM,可用Excel.

微服务拆分之道

- - DockOne.io
微服务在最近几年大行其道,很多公司的研发人员都在考虑微服务架构,同时,随着 Docker 容器技术和自动化运维等相关技术发展,微服务变得更容易管理,这给了微服务架构良好的发展机会. 在做微服务的路上,拆分服务是个很热的话题. 我们应该按照什么原则将现有的业务进行拆分. 接下来一起谈谈服务拆分的策略和坚持的原则.

微服务之saga模式

- -
你已经使用 database ber service 模式. 每个service拥有自己的database. 一些业务事务会跨越多个service,所以你需要来确保data consistency. 例如,假设你正在构建一个电子商务网站,这个网站的用户的会有一个最大欠款限制,应用程序必须确保一个新订单不能超过用户的最大前款限制,但是orders表和customers表不在同一个数据库,所以应用程序不能简单的使用本地的ACID事务.

微服务安全简介

- - 掘金 架构
​由于其可扩展性、灵活性和敏捷性,微服务架构已经变得越来越受欢迎. 然而,随着这种架构的分布和复杂性增加,确保强大的安全措施变得至关重要. 微服务的安全性超越了传统的方法,需要采用全面的策略来保护免受不断演变的威胁和漏洞的影响. 通过理解核心原则并采取有效的安全措施,组织可以加强其微服务架构,并保护敏感数据和资源.