医疗行业数字化转型 —谈谈微服务架构
在数字化转型成为国家战略和国内外科技大厂的成功经验、强大的宣传攻势和推广能力联合左右下,微服务架构(Microservices Architecture,MSA)毫无疑问已经成为当今基础架构的主流话题,短短几年间席卷全行业,仿佛成了每个行业数字化转型的必由之路。
微服务架构的概念
维基百科的定义: 微服务架构MSA是SOA(面向服务的架构)的一个变种,将一个应用程序安排成一个松散耦合的服务集合。在微服务架构中,服务是细粒度的,协议是轻量级的。目标是,团队可以使他们的服务独立于其他服务。松散耦合减少了所有类型的依赖性和周围的复杂性,因为服务开发者不需要关心服务的用户,他们不会把他们的变化强加给服务的用户。因此,它允许开发软件的组织快速成长和做大,以及更容易使用现成的服务。沟通的要求也减少了。这些好处是以维护解耦为代价的。接口需要仔细设计,并作为一个公共API来对待。一种技术是在同一个服务上有多个接口,或者同一个服务的多个版本,这样就不会干扰到代码的现有用户。
这个概念还有点复杂,谷歌的比较简单:
微服务架构MSA是指开发应用程序的一种架构风格。微服务允许一个大型应用被分离成较小的独立部分,每个部分都有自己的责任领域。
从上面两个定义可以看出来,微服务是SOA架构的一个变种/演进,相对SOA里面的服务来讲,微服务里的服务颗粒度更细,可以独立运行。
应用微服务架构的前提--服务超大规模用户群
那么为什么会产生MSA这种想法呢? 知乎这篇文章《微服务架构是什么?》里讲了一个很有意思的故事,解释了为什么会产生微服务这种架构。讲的是一个公司的CTO大刘领了任务要把公司的几套核心系统改造成微服务架构。”原来的老系统是按照几万用户量来设计的,现在跑着没问题,但是眼光要放长远一点,未来这个系统要有几百万人使用,这时,微服务的前提出现了。“
微服务架构的起源,其实就是来自于海外的互联网公司(比如网飞Netflix等,网飞在2004年左右他的在线DVD租赁系统已经要支持上千万活跃用户)为了支持快速扩张的业务而产生的,其目的是服务于大规模和超大规模用户群(百万级乃至亿级)的应用,快速应对C端个人用户的需求,可以快速开发、快速上线/下线、弹性扩展等等,比如大家比较熟悉的春节抢红包、双11等淘宝、京东、微信、头条这些传统的互联网大厂应用,传统行业里像银行业做的相对比较好的招商银行和掌上生活这两个APP的月活用户也有1亿多人。像互联网公司或者招商银行这样量级的用户数使用微服务架构很明显是必须的。
那么医疗行业呢,医疗行业的应用大多数属于院内系统,面向医护和行政人员,全国大部分三级医院的员工,大部分是数千人;号称宇宙第一大医院的郑大一附院,也就1万多员工。就算全部人员同时访问一个系统,传统的单体应用也完全能够支持。很多时候情况这些院内系统运行慢,不够灵活,往往是应用程序设计、代码优化或者底层网络、数据库、操作系统调优的问题,微服务架构非但不能帮助,反而有可能带来更多的不确定性和管理难度。而比如数千万人同时用的健康宝、核酸检测这类全民应用,使用微服务架构确实再合适不过。
微服务的业务场景--可以独立运行的小型应用
上面讲了微服务使用的前提之一,就是要应付庞大的用户量。那么我们看看这么大的用户群一般都是什么应用呢?根据阿里云课堂的介绍,微服务架构应用主要是这几类应用:电商、微博、微信、社交、支付、直播、游戏、广告、物联网等;比如最近最火的“羊了个羊”,就是最典型的小游戏场景。
同样,我们再看看我们的医疗业务场景,医院的挂号、缴费、取药等业务逻辑上跟互联网上的电商、支付类似;在这些医疗业务场景中,最极端的场景,估计就是抢号问题,某些顶级医院的顶级专家可能只有几个号,放号时间又集中在比如下午4点或者中午12点这种极少数的时间段,最极端的情况下可能有几十万人在抢那么几个有限的号源的极端情况,即使在这种情况下,微服务架构是否最佳选择,依然是值得探讨的。
而医院最核心的业务,比如门诊和病房的医生和护士工作站,检验检查、或是支持手术的相关的业务系统,即使现在有各种用来提高效率的技术,依然摆脱不了医生录入医嘱、医生/护士开具检验检查单据,医技人员书写报告,医护人员效率再高,终究还是人。这些业务场景,跟微服务支持下的抢红包、电商、小游戏完全不同,引入微服务架构更是完全没有必要。
微服务架构的核心--服务治理
当然,随着互联网医院、远程医疗、健康管理、数字疗法等面向患者的业务兴起,医疗行业也在逐渐引入微服务架构这种弹性、灵活的理念来构建自己的应用,实现应用的现代化。未来的互联网医疗应用,我们可能很快也会看到医疗行业的杀手级APP,服务几百万用户甚至更多患者。 但是,正如上面概念提到的,“微服务允许一个大型应用被分离成较小的独立部分,每个部分都有自己的责任领域。”,因此,微服务架构的核心其实不是技术路线,而是业务,或者叫服务治理,尤其是医疗行业,有着十分严格的业务监管和规范,很多医院的临床业务,具有天然的有机一体性,不能拆分;有一些服务,确实可能没必要跟其他服务耦合在一起,但是拆分出来的颗粒度多细,也需要具体讨论。说白了,微服务架构核心是服务应该怎么“微”,而不是用哪种技术来支持。如何很好地梳理医院应用系统里面的服务,需要对医院业务和系统有非常深刻的理解,这是需要医院各个部门和厂商一起深度讨论的。而至于采用哪种微服务架构,到底是Spring Cloud/Boot,Istio,servicemesh,则是各有千秋,见仁见智了。
不论是传统的单体架构,还是后来的SOA,以及现在的微服务架构MSA,不管是哪一种,基础架构永远只是底座,存在的目的永远是支持各种医院的业务场景。就像即使微服务已经普及的金融机构,现在也依然是上面三种架构的应用混合并存,即使在云原生如此普及的今天,依然也还有在IBM大型机上运行的单体业务系统。说到底,选择哪一种架构,终究最需要考虑的是投入和产出,重要的是把自己的应用场景想清楚,把需要的资源、人、成本、效果想清楚,然后再决定采用哪种架构,切忌被厂家过度宣传而盲目选择某种技术。
参考文章:
https://zhuanlan.zhihu.com/p/403248211