微服务与架构师

标签: Yurii谈工作 Yurii谈开发 微服务 架构师 软件架构 | 发表时间:2016-11-11 09:47 | 作者:Yurii
分享到:
出处:http://www.luanxiang.org/blog

因为工作的关系,最近面试了很多软件架构师,遗憾的是真正能录用的很少。很多候选人有多年的工作经验,常见的框架也玩得很溜。然而最擅长的是“用既定的技术方案去解决特定的问题”,如果遇到的问题没有严格对应的现成框架,就比较吃力。这样的技能水平或许适合某些行业,但很遗憾不符合我们的要求。

软件架构师到底应该做什么,又为什么这么难做好,这都是近来的热门问题,我也一直在和朋友们讨论。正巧,最近我看完了新鲜出炉的《微服务设计》,所以大概可以谈谈自己的看法了。因为这类问题比较抽象,也没有统一答案,我努力尝试把思路整理清楚,把表达变得流畅。最终有没有讲清楚,说的对不对,欢迎大家给我留言。

今天看来,传统的软件开发(尤其是应用型软件开发)其实是相对简单的。软件运行在基本可靠的单机环境下:CPU提供计算能力,内存提供动态存储,总线提供数据传输,硬盘提供永久存储。这些概念稳定而直观,程序员要完成的,就是调用和组装编程语言提供的各种功能,来满足现实的需求。相比应用程序员良莠不齐的开发水平,无论是操作系统还是硬件环境,都是来自大公司的工业级别的产品,是值得信赖的。

如果把程序要完成的功能比作个人,软件运行的环境比作房屋,那么房屋虽小,却是值得信赖的。对个人来说,只要进去了房屋里,就有相对稳定的环境,相比野外生存就是巨大的进步。当然,如果遇到意外情况,在野外可能生存机会大一点,在房屋里只能与房子“一损俱损”了。不过,通常来看这不要紧。

随着计算机要解决问题日趋复杂,出现了可复用的类库。它们把重复的功能包装起来,只要直接拿来就可以使用。回到房子的比喻,这些东西就好像标准化制作的家用电器,你搬回去、看懂说明书、用起来,就可以大大提升自己的效率。

上面说的是软件内部的进化,软件外部运行模型仍然相对简单——无论要解决什么任务,各种逻辑和资源都是处在同一个运行时(runtime),或者能够方便可靠访问的运行时当中。如果需要提升性能,除去软件本身的优化,就是升级硬件。如果我们需要更快的计算速度,就必须升级CPU;如果我们需要更多的动态存储,就必须升级内存…… 虽然升级需要停机,但是升级之后,性能提高了,运行环境的稳定可靠却不受影响。回到房屋的比喻,在这种思路下,房子还是原来的房子,只是建造得越来越高级,越来越稳定。

即便业界提出了N层模型,整体的复杂度提升也有限。这种划分往往并不是严格按照业务责任,还考虑了实现特性,而且层与层之间的接口仍然能依赖外部环境保持稳定可靠。比如常见的三层模型,表现层-业务逻辑层-数据库层,表现层与业务逻辑层之间往往是函数调用,业务层与数据库层之间的通常是通过安全稳定的内网连接,数据库则是配置很好的机器保证高可用性。回到房屋的比喻,这种思路很像花重金建造几栋紧密相连的专用房屋,各自对应不同的用途。如果外界环境变化不大,这种设计确实很稳定,但也很不灵活。

随着互联网的飞速发展,程序要解决的问题的复杂度也在飞速,原有的思维和范式,既要考虑业务,又要考虑实现,应对起来已经非常吃力了。所以,SOA(面向服务的架构)的概念应运而生。SOA基本脱离了技术实现的细节,引导开发人员从业务和抽象的“服务”角度来看待系统。与传统复用只考虑静态的代码和类库不同,SOA复用的则是动态的运行着的服务。

以上两点,都是SOA相对传统软件开发思想的巨大进步。可惜的是,大多数SOA的学说更倾向于理论和概念的层面,服务的“粒度”究竟定在哪个层级,服务如何落地保证可用性…… 这些问题始终没有取得广泛的共识和规范,对于软件所依赖的环境,SOA也很少涉及,但软件的运行是离不开外部环境的。所以SOA的学说虽然热门,但真正做到了、做好了的例子非常有限。

回到房屋的比喻,SOA不太关心每栋房子到底干什么,只是从逻辑上做个大致的区分:这片房子分给商人,那片房子分给农民,另一个片区的房子分给工人…… 但是SOA并不会具体地规定每个区域里应当安排多少房子,这些房子应当如何建造,如何组合,所以区域里很可能有混乱。

技术继续发展,尤其是移动互联网的兴起,极大地增加了软件所要解决问题的复杂度。从内部来说,性能的增长已经改变了方向,无论CPU还是内存,性能的增长都不再来源于单纯部件的提高,而更多来自多个普通部件的协同工作。如果说传统的性能提高是从纵向上考虑,现在则是从横向上考虑,承载计算能力的不再是“一颗高运算速度的CPU”,保存动态数据的也不再是“一片大容量内存”。玩法变了,程序的思维和编写范式也需要随之进行调整。

从外部来说,性能提升而运行环境仍然稳定的好事不复存在,运行环境日益复杂,可靠性也随之下降,已经没有哪家软件和硬件厂商能为系统提供足够可靠的运行环境。这种外部的挑战很难和以前一样依靠外部供应商来解决:廉价服务节点莫名崩溃很可能是家常便饭,如果网络完全要求节点自身质量过硬以提供高可用性,不但代价高昂,而且违背了网络设计“容忍故障”的初衷;大量程序调用现在通过网络而不是本地进行时进行,几乎无处不在的超时限制会逼迫大家采用异步调用,传输速度和稳定性也会受到极大限制——分布式系统设计中的重大谬误之一就是认为“网络是可靠的”。

更糟糕的是,SOA未能解决的粒度问题变得要紧起来。传统的软件系统大致都有规格说明书,在设计时就要考虑每个子系统的承载能力,而且这些能力大致是彼此协调彼此关联的,系统运行时应当保证压力不超过设计规格。但是现在,业务的飞速发展很可能把段时间内就压力集中到单个服务甚至其中的少数功能上,跨服务的功能很可能又需要迅速组合成新的服务,而这种变化是事先根本无法预料的,很容易暴露出服务定义的粒度问题。再者,从整体上考虑,每个服务既要保证自己的稳定,又要相对隔离以限制故障的影响,同时还要适度容忍其它服务的不稳定,最终才能从总体上保证系统的稳定。这,也是对传统开发思维的一大挑战。

在这种局面下,“微服务”应运而生了。承接SOA的概念,它把系统按照业务责任划分为彼此独立的多个服务,既保证了概念的清晰和自洽,又保证了系统的灵活性、伸缩性。面对杂乱不可靠的现实,它又从实现上注重每个服务的自治性,也就是能独立部署,具备自动化、可观察、故障隔离、自动恢复等特性,由此提供高可用保障。同时,微服务又抛弃了SOA中的很多概念,比如难以落地的ESB、UDDI等等。

在SOA尚且没有完整落地的时候,对它有继承有更新有颠覆的“微服务”,极大增加了开发人员的挑战。首先,服务要拆的足够小,又不至于太小,这样才能保证伸缩性并隔离故障;其次,不能因为服务“小”就降低保障级别,维护一堆“小服务”的保障级别,这是极其麻烦的事情;再次,要做到上面这一切,无论是从理论学说上还是从可依赖的软硬件系统上,都没有现成的低成本的解决方案;最后,因为维护的是动态的“服务”,传统静态的“代码所有权”和“机器所有权”的划分不再有效,它们已经融合为统一的“服务所有权”,它属于开发人员、运维人员以及所有相关人员的共同体,这又会带来团队配合与分工的挑战。

回到房屋的比喻,其实这个比喻此时已经完全不合适了。现在的系统更像高度复杂的城市,而不是单独的房屋,所以架构师也不像建筑设计师,而更像城市规划师,他的职责是对城市进行规划,确定每个区域应该做的事情,这些区域应当达到统一的规范要求,又具有随时扩张或缩减的灵活性;同时,他还应当保证这种划分适合对应的专业人员在对应区域工作。

明白了这一点,就可以明白版本管理、持续集成、自动化测试、自动化发布、服务治理、详尽监控等等“磨刀工夫”的价值——没有这些工作,就谈不上微服务的质量和保障级别,也就无法驾驭微服务的体系。

由此,也很容易明白架构师在这个时代要面对的挑战。一方面,他没有现成的足够强大的集成工具,只能靠一堆“稀松平常”的工具组装出整体可靠的系统;另一方面,他又要深入理解业务,把业务拆散成边界清晰的概念,以高内聚低耦合的服务分而治之,还必须考虑到实现的限制——“高内聚低耦合”的原则人人都知道,如果没有可靠的分布式事务管理机制,就不得不把并非“高内聚”的模块聚合起来,但你又要担心业务边界模糊的风险;RESTful固然优雅,但有时候又不得不使用RPC通讯,所以你又要提防RPC带来的强绑定、客户端服务器端同步更新等很多问题……

这一切设计、权衡、决策,并没有成型的理论和学说可以依靠,通常只能完全依赖架构师的经验、理解、思考。所以困难很大,风险也很大,如果做得好,收益也是非凡的。而这,恰恰是架构师的价值所在。

相关 [服务 架构师] 推荐:

微服务与架构师

- - 乱象,印迹
因为工作的关系,最近面试了很多软件架构师,遗憾的是真正能录用的很少. 很多候选人有多年的工作经验,常见的框架也玩得很溜. 然而最擅长的是“用既定的技术方案去解决特定的问题”,如果遇到的问题没有严格对应的现成框架,就比较吃力. 这样的技能水平或许适合某些行业,但很遗憾不符合我们的要求. 软件架构师到底应该做什么,又为什么这么难做好,这都是近来的热门问题,我也一直在和朋友们讨论.

系统架构师JD

- - CSDN博客架构设计推荐文章
国内大型的物流企业,专业从事国内公路运输和航空运输代理. Foss项目的架构设计,包括需求分析,模块设计,系统结构设计,关键功能的开发,技术难题的解决,对团队质量输出的把控等等. 1、熟悉WebLogic/Websphere/JBoss等一个以上大型应用服务器,熟悉Linux及应用服务器集群. 2、 具有丰富J2EE架构设计经验,具有大型基于J2EE体系结构的项目规划、系统架构设计、开发经验.

从“架构师书单”讲开去

- 黄立 - aimingoo的专栏
琉璃要我推荐一下给工程师们的各阶段的书单,这件事被我压在手边好些天了已经. 然后呢就看见了公司内网中孙坚的一份推荐. 其实那份书单的一些信息也是有出处的(或者说有类似介绍的地方),是江南白衣的另一份架构师书单,目前已经“翻新”到2009年版和第3版了:. 看来白衣兄的确是要把这份书单做到穷极. 但事实上我在看到他的最初版的书单时,就提出过反对意见:.

迷你书: 架构师(8月刊)

- 去北方-Jack - InfoQ中文站
InfoQ中文站的电子杂志《架构师》(2011年8月刊)出炉了. 本期的主编是InfoQ中文站总编辑霍泰稳. 本期《架构师》月刊专题为云计算的安全风险. 安全风险”作为云计算中重要的一环,一直备受关注,本期的专题我们和IEEE合作就这一话题进行深入讨论,并借助一个调查看看当前已经实施云计算的企业是如何看待云计算和安全的.

软件架构师的沟通修炼

- - 博客 - 伯乐在线
在架构师的角色中,沟通是要求有效果的必备技能与工具. 换句话说,沟通是架构师指示别人或群体完成特定行动唯一真正有效的手段. 架构师通常没有对为其项目工作的他人的直接管理权. 他们的项目往往是跨部门的,也可能会跨好多个行业单位. 由于不能直接管理他人,所以架构师指示别人或群体完成特定行动的能力就受到限制.

一线架构师实践指南(一)

- - CSDN博客架构设计推荐文章
       从本质上,架构设计是需求驱动的,而不是模型驱动的. 但当很清楚需求却依然设计不出架构时,就说明“需求驱动的架构设计”的总结还“缺点什么”. 架构设计是一门艺术,不可能把“一桶需求”倒进某台神奇的机器,然后等着架构设计自己被“加工生成”完毕,因此“需求驱动的架构设计”的总结给架构师的启发不够.

一线架构师实践指南(二)

- - CSDN博客架构设计推荐文章
Conceptual Architecture阶段.        有经验的架构师不会一上来就关注如何定义“接口”,他们在大型系统架构设计的早期比较注重识别重大需求、特色需求、高风险需求,据此来设计概念架构. 概念架构是对系统设计最初构想,就是把最关键的设计要素和交互机制确定下来,然后考虑具体技术的运用,设计出实际架构.

系统架构师笔记(二)

- - CSDN博客Web前端推荐文章
今年的系统架构师考试马上就要开始了,在此进行了一次核心要点总结,与大家一起分享. 七、架构权衡分析法:ATTM(Architecture Tradeoff Analysis Method). 评价软件架构的一种综合全面的方法. 这种方法不仅可以揭示出构架满足特定质量目标的情况,而且(因为它认识到了构架决策会影响多个质量属性)可以使我们更清楚地认识到质量目标之间的联系——即如何权衡诸多质量目标.

系统架构师笔记(一)

- - CSDN博客架构设计推荐文章
今年的系统架构师考试马上就要开始了,在此进行了一次核心要点总结,与大家一起分享. 1、性能:系统的响应能力,即要经过多长时间才能对某个事件作出响应或者在某段时间内系统所能处理事件的个数. 架构设计策略:增加计算资源、改善资源需求(减少计算复杂度等)、资源管理(并发、数据复制等)和资源调度(先进先出队列、优先级队列等).

软件架构师的职责

- - 研发管理 - ITeye博客
架构师需要参与项目开发的全部过程,包括需求分析、架构设计、系统实现、集成、测试和部署各个阶段,负责在整个项目中对技术活动和技术说明进行指导和协调.     在项目开发过程中,架构师是在需求规格说明书完成后介入的,需求规格说明书必须得到架构师的认可. 架构师需要和分析人员反复交流,以保证自己完整并准确地理解用户需求.