浅谈服务化和微服务化(上)

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

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

 

1.      官僚不是服务化

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

 fwh-1.jpg


 

2.     烟囱不是服务化

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

 

fwh-2.jpg

 

3.     超链接不是服务化

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

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

 

fwh-3.jpg

 

4.     REST 不一定是服务化

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

 

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

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

 

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

 

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

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

 

fwh-6.jpg

 

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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


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

 


 

 

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


下篇,再讲讲我对微服务的理解,敬请关注。



【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。