南京IAS架构师峰会观后感

上周六,周日在南京举办了IAS架构师峰会,这么多人的技术分享会还是头一次参加,大佬云集,涨了不少姿势。特此一篇记录下印象深刻的几场分享。由于全凭记忆叙述,故只能以流水账的形式还原出现场的收获。

大型支付交易平台的演进过程

大型支付交易平台的演进过程

陈斌,《架构即未来》译者,易宝支付CTO。

交易系统具备以下特点,交易量大,并发度高,业务敏感度高,响应速度容忍度低…从而使得支付交易平台需要有以下的特点:

  • 高可用:7X24*365随时可用
  • 高安全:需满足PCI-DSS要求
  • 高效率:每笔交易的成本要低
  • 高扩展:随业务的快速发展扩张

从以上几点话题引申出了系统扩展的三个阶段

X轴扩展–扩展机器

也就是通俗意义中集群方案,横向扩展,通过添加多台机器负载均衡,从而扩展计算能力,这是最简单粗暴,也是最直接易用的方案。

Y轴扩展–拆分服务

当水平扩展遇到瓶颈后,可以进行服务的拆分,将系统按照业务模块进行拆分,从而可以选择性定制化地扩展特定的模块。如电商系统中拆分出订单模块,商品模块,会员模块,地址模块…由于各个模块的职责不同,如订单模块在双11时压力很大,可以多部署一些订单模块,而其他压力不大的模块,则进行少量地部署。

Z轴扩展–拆分数据

服务拆分之后仍然无法解决与日俱增的数据量问题,于是引发了第三层扩展,数据的分片,我理解的sharding,不仅仅存在于数据库,还包含了redis,文件等。

另外陈斌老师还聊了一个有意思的话题,系统可用性下降的原因根源是什么?最终他给出的答案是:人。系统升级后引发的事故80%是由于人的误操作或者触发了bug等人为因素导致的,是人就会手抖。借此引出了单元测试,持续集成,持续交付的重要性。健全这三者是保障系统可用性的最大利器。

在技术晚宴,陈斌老师又分享了一些管理经验:如何打造一支优秀的技术团队

分析了构成团队的四要素:

  • 人员:健全职级体系,区别考评,挖掘潜能,及时鼓励,扁平化管理
  • 组织:面向产出,利于创新,敏捷小团队
  • 过程:聚集问题的根源,适当地使⽤用ITIL,不断优化过程,自动化取代人工
  • 文化:鼓励分享,打破devops的边界,鼓励创新,树⽴立正确的技术负债观

对于技术人员来说可能有点抽象,不过对于立志于要成为CIO的人肯定是大有裨益的,具体的理解可以参考《架构即未来》中的具体阐释。(ps:这里的架构并不是指技术架构,别问我为什么知道,问问我看了一半后在落灰的那本书,你什么都明白了)

轻量级微服务架构实践之路

轻量级微服务架构实践之路

黄勇,特赞科技CTO,《轻量级微服务架构》作者。

非常具有人格魅力的一位演讲者,这可能是当天最有价值的一场分享。

他首先提出了一个问题:什么是微服务?怎么理解这个’微’字。随后他给出了自己的理解:微=合理。一知半解的微服务实践者可能盲目地拆分服务,微并不是代表颗粒越小越好,用领域驱动的术语来说,微服务模块需要用合适的限界上下文。黄勇老师给出了4个微服务拆分的技巧:

  1. 业务先行
  2. 由粗到细
  3. 避免耦合
  4. 持续改进

非常实用且具有指导意义的4个思想,当你还在犹豫到底该如何拆分你的模块时,可以尝试先从单体式开始开发,业务发展会指引你拆分出合适模块,合适的粒度。当一个个业务被剥离出Monolithic这个怪物,持续重构,持续改进,这样可以指引你深入理解微服务。

随后给出了轻量级微服务架构的技术选型,非常有参考价值。

轻量级微服务架构

其PPT总结了很多经验list,可以在文末链接获取。

顺带一提,没记错的话黄勇老师介绍到其公司的语言栈有:Java,Node,Go,在后面其他老师的分享中集中介绍多语言栈的意义。

《轻量级微服务架构》上下册一起购买,赠送“技能图谱”,感兴趣的朋友可以阅读一下他的书籍。购买链接 ps:谁让我白得了一本上册呢。

Cloud Native架构一致性问题及解决方案

Cloud Native架构一致性问题及解决方案

王启军,华为架构部资深架构师。

王启军老师则是带来了如今微服务架构最难的一个技术点的分享:分布式中的一致性问题。

他的分享中涵盖了很多经典的分布式一致性问题的案例,如两军问题,拜占庭将军问题。引出了经典的CAP理论,NWR,Lease,Replicated state machine,Paxos算法。由于时间问题,45分钟根本无法详细地介绍他们的流程,实属可惜。

一致性问题被分成了两类,包括:

以数据为中心的一致性模型

  • 严格一致性
  • 顺序一致性
  • 因果一致性
  • FIFO一致性
  • 弱一致性
  • 释放一致性
  • 入口一致性

以用户为中心的一致性模型

  • 单调读一致性
  • 单调写一致性
  • 写后读一致性
  • 读后写一致性

这么多一致性分类太过于学术范,所以业界通常将他们简单的归为了三类:

  • 弱一致性
  • 最终一致性
  • 强一致性

对于各个一致性模型的科普,以及一些事务模型和解决方案如2PC,3PC,TCC型事务,PPT中都给出了简单的介绍。

技术架构演变全景图-从单体式到云原生

技术架构演变全景图-从单体式到云原生

千米网首席架构师,曹祖鹏(右) & 当当网首席架构师,张亮(左)。知名开源框架sharding-jdbc,elastic-job作者。

别开生面的面向对象技术分享。也是我本次大会最期待的一场分享,分享涵盖的知识点很多,深度和广度得兼,其分享中阐释了云原生,服务编排、治理、调度等2017年处于潮流前线的技术热点,通俗易懂地介绍了service mesh的概念,让观众在惊叹于互联网技术变化如此之快的同时,也带来了很多思考。

分享中还对比了Spring Cloud和Dubbo,当当网和千米网的团队都向Dubbo贡献过代码,Spring Cloud又是国内话题最多的框架之一,台下观众对这样的话题自然是非常感兴趣。张亮老师着重介绍了Spring Cloud相关的组件,而曹祖鹏老师重点对比了其与Dubbo的区别。

Spring Cloud的出现同时宣告了Cloud Native云原生的首映,其为微服务的构架带来了一整套初具雏形的解决方案,包含了Zuul网关,Ribbon客户端负载均衡,Eureka服务注册与发现,Hystrix熔断…并且有强大的Spring终端组件支持,活跃的社区,丰富的文档。

随后,介绍了云原生的技术全景图:

技术全景图

之后,简单解释了治理,编排,调度的概念后,并重点介绍了服务治理,编排相关的技术栈,老牌的nginx,netflix ribbon,zuul等产品,如今风靡的k8s。尤其是介绍到service mesh这一比较新的概念时,分析了服务的治理,编排,调度从应用层转移到基础设施层的趋势,无疑是非常exciting的一件事。如dubbo等rpc框架的服务注册发现依赖于zk,consul,而spring cloud的服务注册发现组件eureka,以及其客户端路由组件ribbon,服务端路由组件zuul等都是从应用层解决了服务的相关问题,而service mesh提供了一个新的思路,从基础设施层解决服务的相关问题:

service mesh

如果service mesh的开源产品Linkerd和Lstio能够保持好的势头,配合k8s在运维层的大一统,很有可能带来架构的新格局。与此同时,java一枝独秀的时代即将宣告终结,多语言的优势将会被service mesh发扬光大,使用go编写高并发的模块,使用java编写业务型模块,nodejs打通前端模块,python处理性能要求不高模块提升开发效率…而不用关心多语言交互的问题,这都交由service mesh解决,这几乎是2017最潮流的知识点,没有之一。

(引用一张jimmysong博客中的图片)

云原生演进

如上图所示,得知Spring Cloud竟然是2015兴起的技术栈时,可能还会有些吃惊,等到可以预见的2018,运维层的技术栈开始向上侵蚀应用层的技术栈,不得不感叹互联网技术的日新月异。

两位老师从可追溯的历史到可预见的未来展现了云原生架构的演进史,着实给小白们好好科普了一番。

番外

此次技术分享会收获颇丰,不枉我早上5点起来赶高铁去南京了。但还是得吐槽一句,这门票真tl的贵啊,就不能便宜点吗!!![微笑face]

其他分享者的话题也很有意思,不仅包含了微服务方向,还囊括了人工智能,机器学习,运维,领导力,架构演变,游戏架构等多个方向,笔者选择性的介绍了一些,全部的PPT可以在下方的链接中获得。

https://pan.baidu.com/s/1eSbCu5c

分享到