本文为《持续演进的Cloud Native:云原生架构下微服务最佳实践》一书序文。作者从全局视角出发,全面阐释Cloud Native 的关键技术,以及其衍生出来的工具、团队文化等核心要素,对于正在部署微服务架构或开展云原生业务的企业和组织而言,终于有了面向落地的务实参考和全面指导。
PART
01
架构没有绝对的对与错
在技术的领域里,并不存在“上帝”。没有人的每句话都是对的,没有人的所有思想都能被别人所接受。
我经常在公司范围内培训,首先是灌输架构思想和解决方案,然后会在实战演练中模拟一个比较简单的业务场景,把所有人分成 4 个团队,每个团队大概有 10 个人。结果发现,每个团队最终形成的架构图总有很大差异,很难评价一个团队的做法是对是错。例如,是要拆分为 3 个服务,还是 5 个服务,他们有各自的理由,除非比较明显的问题,否则你很难以一个理由去否定另一个理由。原因只是各个团队站在了不同的维度综合判断、权衡,形成了自己认为满意的架构方案。因此,架构没有绝对的对与错,只是在不同的角度做出的决定而已。
PART
02
架构很难被衡量
每个公司的管理层都希望尽可能地去衡量架构的先进性,希望认清差距,向着好的架构方向不断演进。然而架构很难被衡量,须同时具备差距特别明显、制定指标的人能力达到一定高度、业务场景比较接近这三条才有可能衡量。当然我们可以去制定一些指标,这些指标应该是参考性的,作为一个自检项,而不是评价标准。从这个角度看,并不是符合Cloud Native 就是好的,不符合就是差的,当不符合时,你的理由是什么?你站在问题的哪个角度?
Martin Fowler 曾说:“优秀的技术人员的观点胜过任何度量,尽管它是主观的。”
因为你无法统一每个人关注的点,以及对各自关注的点的重视程度,所以架构很难被衡量。
PART
03
架构需要持续演进
在传统企业中,架构设计是一个很重要且很耗费时间的过程,需要经过很多轮审核,架构文档动辄几百页,而且这个文档绝对不能有没考虑到的问题,必须面面俱到、接近完美。例如,目前系统还没有用户,就要为未来 1 千万的用户耗费精力解决性能问题,而且软件永远有你想象不到的问题发生。实际上我们描述的是一种静止的架构,这种架构每次变更都需要耗费巨大的成本。如果此时恰好出现了一个基于敏捷思想的竞争对手,则会形成一种鲜明的对比,他们不去考虑太长时间之后的事,出现什么问题就解决什么问题,因为有可能一年以后这个项目死了,也有可能用户人数突破 1 亿,系统需要进行大规模重构。
总之,未来是不确定的。可见,架构是锤炼出来的,而不仅是设计出来的。
反应速度是传统企业的硬伤,这不是通过加班就能解决的。可以看一下互联网巨头们每年的发布次数,动辄每年发布几百万乃至上千万次,每个服务每天都在发生变化,每周可能都会上线。在如今这个快速发展的世界里,你无法依赖一个人去做所有的决策。这就需要发挥所有成员的主观能动性,也就是说,架构应该交给一线决策。回到前面提到的问题,服务怎么拆分更好?我想只有深入了解需求、场景、目标甚至自身条件之后才能做出决策。并且,架构的演进不是一蹴而就的,而是一个长期发展的过程。
PART
04
变革需要坚决
历史上的变革大多阻力重重,因为一旦变革就意味着打破原有的“默契”,打破原有的“潜规则”,而“顽固派”通常是原有文化的受益者,他们通常不会反对变革,而是通过“我们不能完全照抄,要走出适合我们的路”来促成妥协。如果变革过程中遇到任何风吹草动,就更会给“顽固派”各种理由“走自己的路”。这也就是为什么我们熟知世界领先 IT 企业的技术、研发流程和企业文化,而就是学不会的原因。
这时候需要的是企业领导者的果断、坚决。只要方向没错,就要坚持,决不动摇。下面这段话是马云对刘振飞(阿里技术保障部负责人)关于阿里云内部争议的回复,反映了一个领导者在企业变革过程中起到的作用。
在王坚加入阿里之前,我跟教授(指曾鸣)讨论公司的未来,觉得云计算和大数据代表未来,对国家和社会的发展有长远的意义,所以我们要干,这是第一点。但是怎么做云计算、大数据?我们谁也不知道。现在来了个人叫王坚,他说:“我知道怎么做”,为什么不支持呢?这是第二点。第三点,即使万一做失败了,那也没关系,咱们的人倒下 70%,还有 30%活着,咱们活下来的人打扫战场,换个方向继续干,总要把它做出来。
PART
05
写代码不同于搬砖
如果是搬砖,那么效率高的人和效率低的人之间的差距不会太大,因此每个人每天的工资都是相对固定的。但是在如今这个知识爆炸的时代,对于从事软件行业的群体来说,效率高者的工作效率比效率低者的可能高出几十倍、几百倍,优秀的人能写出更高质量的代码,能够预测问题。而在这个行业越是优秀的人才越是稀缺,因此很多互联网公司都愿意花大价钱去招一些更优秀的人。
优秀的人不愿意来,不一定是因为钱。花钱雇佣优秀的人是一方面,怎样管理这些人又是另外一方面,用管理搬砖者的方式来管理他们是不行的,管理优秀的人需要给予他们更多的信任,需要营造一种公开透明、自由高效的环境。
PART
06
关于《持续演进的Cloud Native》
为什么会出现 Cloud Native 这个概念呢?无论是云化、平台化,还是微服务架构,又或者是敏捷开发、自动化,都只是描述了几个点,而 Cloud Native 更像是一个面,通过它把这些点都关联起来了。某几个点做得很好而忽略了其他点通常会走入误区。例如,某些团队只关注服务拆分,而忽略了工具、组织对微服务的影响,最终效果并不理想。又如,要提升系统的可用性,只是从技术的角度去考虑是不够的,还要考虑如何通过自动化测试提升可用性,如何通过 Code Review 提升可用性,以及当故障发生时如何快速修复。我希望通过个人的工作经历以书的方式传递一些这方面的经验教训。
本书分别从架构、研发流程、团队文化三个角度全面论述 Cloud Native,因为只有三方面配合才能达到理想的效果。我见到过无数失败的案例,绝大多数都是因为考虑得比较片面,例如单纯从架构角度进行变革,或者单纯从研发流程角度变革。我们希望模仿Google、Facebook、Amazon、Netflix 等领先企业,但是往往高估了架构的影响力,而低估了研发流程和团队文化的影响力。实际上,研发流程和团队文化对架构有着非常重要的影响。本书以 Cloud Native 的起源、诉求及组成开始,全面描述了 Cloud Native 的各个方面。从架构角度阐述了如何实施微服务架构,如何构建敏捷基础设施及平台服务。同时,从可用性、可扩展性、性能、一致性等角度描述了微服务架构中产生的问题及解决方案。最后,分别描述了 Cloud Native 下的研发流程和团队文化。
本书比较适合技术管理者、架构师和有一定基础的技术人员阅读,特别是传统软件企业的技术领导者,以及希望向互联网公司转型的或者转型失败的企业技术领导者。此书将帮助这些人少走弯路。还有一些比较有经验的高级研发人员,阅读此书也利于系统掌握Cloud Native 的关键技能。无论如何,都希望此书能给你带来较好的体验,使你获得启发。
本文分享自 博文视点Broadview 微信公众号,前往查看
如有侵权,请联系 cloudcommunity@tencent.com 删除。
本文参与 腾讯云自媒体同步曝光计划 ,欢迎热爱写作的你一起参与!