码迷,mamicode.com
首页 > 其他好文 > 详细

【华为云技术分享】浅谈服务化和微服务化(上)

时间:2020-02-29 16:20:08      阅读:175      评论:0      收藏:0      [点我收藏+]

标签:自动化   lan   而不是   调用   解耦   bsp   没有   在线   区域   

微服务是近期非常热门的话题,芸芸众生言必谈微服务。但是,在实践过程中,我们发现一些项目,貌似用着微服务的技术,但做出了非服务化的应用,非但没有达到目的,反而徒增了架构的复杂性,让人汗颜。因此,在微服务之前,有必要搞清楚什么是服务化。

1. 官僚不是服务化

河北省武邑县需要往返6次才能办一个护照,深圳小孩出生要跑社保局、街道办、派出所,这些都是服务化程度低的标志。官僚化的程度越高,服务化的程度就越低。买房子相对好些,在入伙的时候,水、电、煤气一站式搞定。

技术图片

2. 烟囱不是服务化

最近一次出差,使用了 e系统、i系统、s系统 等好几个应用,经过长期的优化,这几个系统的体验都还算不错。但用起来总感觉怪怪的,问题在什么地方呢?很多时候,当你需要找一个想要的信息,比如航班信息时,你往往不知道要到那个系统去查。 e系统、i系统、s系统都是品牌和口碑很好的应用,但放在服务化场景下重新思考,我们很容易的发现:烟囱化的应用不是服务化。

技术图片

3. 超链接不是服务化

既然烟囱不是服务化,那我用超链接把各个烟囱串联起来,是不是就是服务化了呢?显然不是,简单的超链接让事情变得更加糟糕,而不是更好了。超链接就如同单向的门,为了打通两个房间,我们需要安装两个单向的门,房间数更多的时候,门的数量也更多,最后组成了一个什么呢?对,一个迷宫。

服务化的系统,不是仅仅将相关功能连接在一起,而是有机的整合、简化成 One System,让基于当前场景的用户感觉可以流畅的处理端到端的业务,而不必到处在风格迥异的系统间跳转以致摸不着头脑。

技术图片

4. REST 不一定是服务化

我做了一个应用,有前台,有后台,前台通过REST(或者SOAP、RPC等)调用后台,是不是就服务化了呢?其实不然,这个还可能是一个烟囱,一个伪装了的烟囱。

5. 单体应用不一定不是服务化

服务化(SOA)是一种构建分布式应用的方法,本质上是实现能力在分布式环境中的重用。单体应用通常跟微服务应用对立起来,单体应用并没有跟SOA对立起来,单体应用也一样可以暴露足够的服务供其他的分布式应用来使用(与烟囱的区别),从而实现服务化的重用。

另外,单体架构并不一定不是好的架构,这取决于应用的复杂度。一个初创的公司,要在互联网-上开展业务,由于业务规模不大,业务复杂性有限,码农数量也不多,这个时候,单体架构就是最合适的。即使对于华为这样的大型公司,在某些独立的领域,如果一个单体应用能很好的覆盖完整业务场景,单体架构仍然是合适的。

6. 组织结构服务化才能实现服务化。

俗话说,组织架构决定技术架构。有烟囱式的组织架构,很容易导致烟囱式的系统。要实现服务化,必须打破原先一个团队搞定一个烟囱的组织架构,变为一种服务化的组织架构。应用的前端和后台应该采用完全不同的设计方法,前台UI的设计是完全以用户为中心的,而后台的服务设计则是以业务为中心的。前台和后台最好归属到不同的团队,以避免他们造烟囱的强烈生理冲动。

技术图片

7. 针对完整场景的才是好的服务化。

割裂的场景导致割裂的体验,好的服务化设计都是针对完整的场景的。让用户在端到端的场景中拥有完整的、一致的、简单的、明确的体验。什么是端到端完整的场景呢?

o 差旅就是一个完整的端到端场景,从出差申请,到机票预定、酒店预定、签证申请,再到出差报告、报销整个一条*LONG*服务。

o HIC也是一个完整的端到端场景,从应用注册,到应用开发、测试、资源申请、配置管理、持续集成、持续交付、运维自动化,整个链路覆盖。

如果割裂开来,针对部分场景设计一个应用,另外的场景设计另外一个应用,则很容易形成烟囱。即使只是针对完整场景中的任何一个遗漏,都会导致服务化体验的劣化。

8. 服务化的必然结果,不一定是业务中台。(2019年12月修订)

最近中台很火,微服务拆的太多了,只好换个名义去整合。貌似不搞中台,都不好意思跟别人打招呼。但是服务化一定会走向中台吗?其实未必。

前一阵跟冉启春交流很有启发,启春认为,现在做业务中台成功的只有阿里。对于这个观点,我必须毫不遮掩的表示赞同。这里并不是说其他公司技术不好,做不成中台,而是目前具备需要中台的企业并不多。阿里有很多相似但有明显差异的前台业务,比如淘宝、天猫、1688、聚划算等,所以需要把通用能力沉淀到中台去解决,比如订单中心、商品中心等,而在前台去解决业务的差异化。

 

为什么说只有相似但不相同的多个前台业务才需要中台呢?我们分析如下三种场景:

a. 有多个前台,但前台是雷同的,则通过服务化就很好的可以解决,比如爱奇艺和爱奇艺(台湾)

b. 如果前台的差异过大,完全无法沉淀业务能力到中台,那也没有必要做中台,比如商城和金融服务。

c. 当前正处于业务的发展初期,业务还未定型,需要更敏捷的发展,则也没有多大必要构建中台。

总结来说,中台更多的是一种组织级的战略,通过中台的能力沉淀,支持不同前台的共享和差异化。

 

具体到华为IT来说,现在也在搞中台。比如合同中心、用户中心等,关键在于发掘相似但有明显差异的业务,从几个维度可以思考

a. 不同类型的业务,如设备、软件、服务

b. 不同区域的业务,如中国区、海外各区域

c. 不同BG的业务,如CBG、EBG、CNBG的业务

那到底哪个是相似但有明显的差异的业务?需要深入了解这些业务,并深入思考。

总体来说,服务化的目标,是通过更加服务化的组织和完整的服务化的实践,构建针对完整业务场景的一站式的ROADS用户体验(套用一句流行的话)、更加解耦的架构,从而实现全流程的在线处理、更高的业务作业效率,提升业务数字化转型效果。我们不能过度强调技术,而忽略体验,因此,理解什么是服务化比理解什么是微服务更加重要。

作者:quitgame

技术图片

【华为云技术分享】浅谈服务化和微服务化(上)

标签:自动化   lan   而不是   调用   解耦   bsp   没有   在线   区域   

原文地址:https://www.cnblogs.com/huaweicloud/p/12383441.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!