我对微服务的一些idea

pm45e 9年前

Docker成功了,带动了微服务的兴起,让我也联想到了很多年前我读书时候的一些人和事,其中让我印象最深刻的是杨芙清院士在软件构件方面的先驱性的研 究。其实很多时候一个事情失败或者做得不尽人意,不是因为事情或者想法不好,而是时候未到。我觉得服务器的未来属于微服务,属于Docker,属于构件化 的软件开发方法!

微服务microservice,中心思想是将构架打散,切分成粒度最小的功能模块,用容器也好,进程也好单独运行这些模块,并使用网络将这些分 解的模块连接起来通过协调服务来完成特定的工作;这样做可能是将分布式进行到极致的结果。那么微服务的核心就是切分了,用一个字就是——分。

划分,切分问题是现在不管是学术界还是工程界解决复杂问题,协调复杂问题的一般方法,也是最重要的一个方法。比如:框架式的建筑方法可以10几天 就建成一栋高楼,得益于框架式,功能划分的建筑构件的拼接;美国最新的布什号尼米兹级航母就是将功能不同的部分分别在不同地方制造完成,然后统一拼装完成 的。

 我对微服务的一些idea

 我对微服务的一些idea

将复杂的问题划分为不同大小的子问题,然后各个击破,最后归纳,总结成一个问题的解的过程在分布式领域叫做Map-Reduce;在程序领域叫做面向对象;在工程领域叫做构件化;在算法领域叫做分治或者动态规划——总之,它其实已经相当普遍了。

我记得我读研究生的时候,第一天入学就是听杨芙清院士的讲座,印象很深刻,题目就是软件构件技术的未来(外面挺的最多的就是北大青鸟计划,后来怎 么就跟计算机教育联系在一起我不是很清楚)。它的核心我想就是现在说的利用微内核或者微服务的方法,将操作系统这么复杂的系统工程切分成若干个小的模块或 者说构件,然后通过调度,协调这些模块或者构件的运行时状态来共同完成一个特定的任务。这个思想其实是非常超前的,至少在将近10年前的中国;我也听得云 里雾里,我想Linux通过单一内核的设计减少IPC,来提高效率,节约内存,为啥还要搞个纯微内核的系统,Mix已经是个失败的案例了,我觉得可能噱头 的成分更多一些。后来我专门选修了“软件构件”这门课,讲的都是理论上的东西,我也没大听明白,后来上课的老师居然也上不下去,跑了…… 好吧,好在那个时候开始流行WebService与SOA,我就转修WS与SOA了,讲课的老师都是从国外回来的,比较有个性,讲授WS的是个日立公司的 高级研究员,女老师;SOA的老师是一个海归,在研究“动态互联网”——当初我花了很长的时间才弄明白他要干什么(基于P2P技术的自发现互联网模式,就 是人们在分享信息的时候不需要通过输入网站,或者通过搜索引擎,就能通过你的喜好推送给你。想想还是蛮智能的,他带着学生写了很多代码,包括新的浏览器, 路由模式,还带着学生打了不少架,后来怎么样我就不知道了……),毕竟太超前,但是由此可见,国外的早在10几年前就在搞的东西,可能我们现在都还停留在 炒作的阶段。总之,那几年大家都在谈论SOA与WebServices(这里注意,Webservices后面一定要带s,不然就不对),但是真正明白中 间道理的并不多,都是在炒作而已,基本也就是在用一些现成的工具CFX,微软的傻瓜工具搭建一些系统,生搬硬套罢了;后来直到 Steve Y对Google的吐槽才使我重新了解到了WebServices与SOA的价值。当然,后来就是云计算的横空出世了。

总之,那几年对于分布式、软件构件的理解是碎片的,不系统也不真实。后来,Docker出来了,后来微服务被广泛的认同了,我想,国外已经把这套 研究成熟了,开始传播,我们只要吃下就行了。这很自然让我联想到2006年听到杨芙清所提出的软件构件理论,微服务其实就是当年杨教授所提到的软件构件, 只是现在改了个名字,叫微服务,而且很多人都是通过Docker引出的微服务,所以有种故事人非的感觉。不管怎么样,有一点是值得留意的,当我们对一个事 物认识越深刻,就越能把事情剖析得越细分越清楚。比如:西方科学诞生自宗教,开始是天文学,为了证明上帝的存在,地心说等等而设立的,后来发现事情越来越 复杂,也得到了很多观测数据,为了处理与分析这些数据,诞生了数学;通过数学的演绎,我们总结出了一些物体与物体的运动规律,于是有了物理学诸如此类;随 着我们对事物本质认识越来越深刻,逐步诞生了很多学科,这些学科就是对问题的分类,有些科学家终其一生都是在一个很狭小的分类学科里面耕耘;而将这些科学 研究成果汇聚在一起就是一个伟大的工程。再比如,面向对象的编程方式,它的价值在于对事物的分类处理的思维方式第一次被引入到程序设计中来了。不管多么复 杂的系统,只要使用面向对象思维去构建,仿佛事情就会容易很多;因为你在分析业务构成的时候,随着对问题本身的研究会不断的将问题分解、细化最后形成模 块,最终构建出庞大的系统;而面向对象的语言则能很自然的教你,或者引导你去将问题细化,分类,然后用通用的设计模式将不同的分类协调好,处理好,就能得 到问题在程序上的一个解;所以,基本所有的OO语言都把类叫做——Class,即分类。这个思考问题的过程就像一个公式一样,只要你能够将Class构建 出来,不管怎么构建它,就能形成问题的一个解。这就是划分问题的力量所在。

我想,对于微服务,对于Docker,我想后面几年将会有很大的发展,集中在:
1、对于现在程序研发与部署方面的改革。之所以叫改革,我想会颠覆很多以往的思考问题的方式,就像OO出现改变了人们编程时的思维方式一样。到时候,人们 会常常想我需要什么,而不是我要构建什么;比如我需要一个数据库,我需要一个登陆模块,我需要一个分析模块;基于这些会出现一些更高级的编程语言;通过编 译这个语言;就能完成服务的构建,就像之前我翻译的一篇文章: 两年之后,再思考Docker的价值,一个基于服务的链接器会代替现在基于本地代码的链接器;服务的获取与部署全部都会定义在编程语言里面,人们写好了程序,那么在运行时程序会自动的查找,生成程序的容器,并通过程序的逻辑将其链接,编排在一起;
2、对于服务的获取。就像几年前大家还在炒作域名,这几年大家发现域名不值钱了,反而APP与公众号成为了服务的入口一样。程序、算法、模块会构件化,程 序的编译器会将不同的业务逻辑,算法编译成一个容器通用的二进制格式,就像ELF一样低层;操作系统,或者说容器的编排工具会根据容器的格式动态或者静态 的去加载,执行这些构件,让它们能够协调运行。

容器是微服务很好的载体,而且他的出现并没有伤害到现有操作系统的构架,但是我觉得容器要发展,必须要有统一的低层二进制格式,统一的服务规范与统一的通信协议的支持。我很期待软件构件化时代的到来的!

来自:http://dockone.io/article/555