咨询
STEP 1 / PROJECT SPECIFICATIONS
我们将在一个工作日内回复,资料保密处理
yjy.wisedu.com
推荐专题 / News
推荐新闻 / News 更多>>
英迈思活动 / FAQ 更多>>
英迈思活动 / Video 更多>>

不构筑大系统后,选择SOA还是转战微服务?

来自:
日期: 2016-11-30
浏览: 14


    不构筑大系统后,选择SOA还是转战微服务?

近日,北京理工大学网络中心李凌老师在简书上原创的一篇文章《从构筑大系统,到编写小应用》得到了圈内人一致好评。李老师认为“做一个大系统这件事在理论上就不现实,更没有实践的必要”


其实,不难猜测高校为什么会有建设大系统的需求。其信息化管理者的心理状态是:我既然花了钱,自然功能越多越好,如果功能不全,将来要用又要另外付费不说,可能还要被领导责怪为什么当初没有想好。这些没有明确使用场景的功能导致了“上线即下线”的怪象:几乎80%的高校都只使用了20%的功能。剩下80%会因为技术、性能、场景的限制,越来越无法满足高校的发展需求,根本用不起来,甚至到下一次升级的时候,发现没有产生任何使用数据。


这20%的需求是厂商乐见的,他们把这些共性的核心需求形成产品版本并向外推广,获得收益回报。而80%的非共性需求需投入很高的人力成本做定制开发和运维,收益很低甚至是负收益,厂家基本不会选择这种发展方向。


所以要尽可能全的功能是个伪需求,能提供尽可能全的功能的系统是个假系统。


不构筑大系统后,选择SOA还是转战微服务?


当前,业内对高校信息化的发展过程已经达成了共识:经过校园网建设阶段(网络化)、单机版系统建设阶段(数字化)、网络平台系统建设阶段(集成化),我们已经进入了信息化服务阶段。平台厂商、工具厂商、应用厂商各自祭出武器,百家争鸣,但主流的模式主要是这两种:基于传统服务总线的SOA模式(文中简称SOA)新兴的、倾向于完全自治的微服务模式(文中简称微服务)。

1、SOA

【百度定义】SOA支持将业务转换为一组相互链接的服务或可重复的业务任务,可以对这些服务进行重新组合,以完成特定的业务任务,从而让业务快速适应不断变化的客观条件和需求。


不构筑大系统后,选择SOA还是转战微服务?

(图片来源于网络)

 2、微服务

【百度定义】微服务是一类将单一应用程序作为由众多小型服务构成之套件加以开发的架构方式,其中各项服务都拥有自己的进程并利用轻量化机制实现通信。这些服务围绕业务功能建立而成,且凭借自动化部署机制实现独立部署。这些服务匹配一套最低限度的中央式管理机制,且各服务可通过不同编程语言编写而成并使用不同的数据存储技术。

不构筑大系统后,选择SOA还是转战微服务?

 (图片来源于网络)

尽管两者都是面向服务的,但从图上很容易看出两者的结构区别:SOA是星状结构,有中间节点;而微服务是网状结构,去中心化。意味着其面向的服务颗粒度和对服务的治理方式有很大区别。


具体怎么理解呢?举个例子,小明和小微最近都在装修新房,但两人采用了不同的方法。

 


不构筑大系统后,选择SOA还是转战微服务?


 

  • 小明的做法

小明找了包工头王师傅做整包,王师傅找来了水电等一系列相关工种的操作师傅。这些师傅由王师傅统一管理、调度和发放酬劳。小明认为这种方式虽有不足,但好处也很明显。

 

好处:

1、小明只需管理王师傅一人,他会根据小明的需求协调和整合资源,过程小明无须操心。

2、由于王师傅找的这几个工人师傅之间经常合作,对彼此的手艺很了解,能通过合作弥补个体的不足,保障交付效果。

不足:对包工头王师傅的依赖过大,如果这个环节出现问题,整个装修工程就宣布失败了,小明的损失会非常大。

 

  • 小微的做法

小微没有找包工头整包,而是自己分别找了各个工种的师傅,并跟他们每个人交代清楚装修需求、各工种进场的顺序、交付时间等。好在他自己精通装修过程,确保最终没出工程质量问题。小微认为这种方式虽然有好有坏,但也适合自己。


好处:每个工种师傅相互独立,一个环节出现问题,可以很快另外找人顶上。同时由于没有中介,能省去一笔中介费用。

不足:小微要直接管理每个工人,而工人相互之间不了解,增加了工程复杂性和管理及沟通成本。


我们替换下例子中的元素,小明模式=SOA模式、包工头王师傅=SOA中的服务总线、小微模式=微服务模式,再来看:

SOA模式: 由服务总线负责对接需求、寻找资源和编排整合资源。服务总线还会定期跟各个接口进行单线通信,了解服务的状态,并反馈给信息化管理者。


比如某应用需要调用学生相关接口的请求后,它负责找到各这个需求相关的5个可用接口,并根据其业务逻辑和关联度对这5个接口进行组合编排,最终生成一个完整的新API暴露给需求方调用。但是这种情况下服务的响应速度变慢,且因为编排后内部耦合度增大,任一个接口出现问题,会影响整个应用的使用。

 

微服务模式:去中心化,内部通信增加,且每个微服务的调用和被调用都具备随机性。而需求方需要自己了解各个服务的状态。


上面的例子在微服务模式下,首先服务调用方需要先逐个了解每个接口是否可用,并找到其中5个相关的可用接口。最终这5个接口会不经过编排,全部被原生态暴露。这种情况下,任一个接口出现问题,随时可以替换成另一个提供同类服务的接口而不影响应用使用。


    这样一来,我们发现生活中对于小明模式和小微模式很好选择。但在高校信息化的实际环境中,要严格根据学校的信息化建设情况、运营能力和发展目标,结合SOA模式和微服务模式的利弊特点综合考虑。

     

     


    不构筑大系统后,选择SOA还是转战微服务?


     

    前不久,复旦大学信息办主任宓詠老师在第四届高校智慧校园研讨会上做了《用流程和数据构建智慧校园》的主题分享,也提到了微服务的模式。


    他认为“自动化测试、持续集成与自动化部署是向微服务架构大规模迁移前必须补偿的技术欠债 。因为微服务架构下,团队需要管理大量服务,其复杂度和测试难度是几何级增加,利用自动化测试能帮助团队快速有效的验证应用;持续集成与自动化部署可保障团队更快速、更容易的修改代码; 缺少持续集成和自动化部署,向微服务架构转型过程会异常痛苦“


    复旦大学已经开始逐渐向轻量化转变,而这个转变的背后,是复旦20年来的信息化积累和一支数十人的专业信息化队伍。


    而更多的高校还在积累阶段。但一定有某一天,行业的发展到达到某个临界点,而后引爆新的技术革命,帮助我们偿还完这些技术欠债,让更多高校真正看到微服务的曙光。那一天,一定会像Google发布“三驾马车”一样,被历史铭记。

     

     



    关键词:
    分享:
    Hot News / 热点新闻
    地址:中国·南京·江宁区将军大道100号金智科技园
    电话:025-68755381   邮箱:marketing@wisedu.com
    传真:+86 0755-2788 8009
    邮编:330520
    Copyright@ 2018-2019江苏金智教育信息股份有限公司 All rights reserved
    犀牛云提供企业云服务