人人都想学架构(一)

最近看了一本书《从零开始学架构》,最早是在极客时间购买的专栏,后来参加博文视点活动的时候,我又拿了一本纸质书,不过最近才看完。客观的说,这本书没有想象的那么好,但也没有太失望,因为架构的书本来就很难写,架构涉及的技术太多了,演变也非常快,就算一个人对架构了然于胸,以什么样的角度写出来也非常不易。

架构师是人人都想从事的一个岗位,种类也非常多,可真正能落地的估计不多,也涉及到很多的方法论,时间长了,架构师有的时候也和年龄挂上了沟,如果有机会我更喜欢接触垂直领域的技术,以点到面,这样学习的更扎实。

每一本书都有其可取之处,看完《从零开始学架构》后,简单做了个笔记,从整体上对架构有个印象,这本书内容相对还是比较浅显易懂的,如果说 《数据结构和算法还是值得学习》 文章中推荐的《数据结构与算法之美》专栏能打10分,那这本专栏可以得7.5分。相对于书,专栏可以留言讨论,这种形式非常好,本书的留言非常精彩,可以说高手在民间。

第一节首先介绍了架构的几个概念,其中一个用户的留言非常的精辟,看了后有种醍醐灌顶的感觉,摘抄如下“架构是顶层设计;框架是面向编程或配置的半成品;组件是从技术维度上的复用;模块是从业务维度上职责的划分;系统是相互协同可运行的实体”。

模块和组件比较容易混淆,模块是为了进行职责分离,而组件是为了重用。框架关注规范,架构关注结构(物理结构,程序结构,系统结构)。

第一节接下去说的是架构的目的,作者总结的很好,架构是为了解决软件系统复杂度带来的问题,这是一个很好的准则,但说的不详细,以前看过 一篇文章 ,对于架构的目的和重要性说的非常好,以后我会分享。

架构是一个决策的过程,在解决问题的时候,必然有很多的约束(经验、成本、资源、进度、业务),而架构就是在技术需求和功能性需求之间做一个平衡。

架构是需求驱动架构而非技术驱动架构,有了架构,在分析设计阶段,需要考虑一定的人力与时间去”跳出代码,总揽全局”,为业务和IT技术之间搭建一座”桥梁”。在IT行业,没有银弹,但有“行业最佳实践”作为指路明灯,这也是架构的作用。

第一节接下去说的是 复杂度三高 ,高性能、高可用、高扩展。高性能解决的问题是让用户有更好的体验,同时在规模变大的情况下能够让性能保持恒定。

高性能的复杂度体现在两个方面,第一就是单机的性能(垂直维度),这个和操作系统关系比较大,可以采用多进程多线程IO多路复用等技术提升性能,或者通过升级硬件提升性能(多核、SSD)。

另外规模达到一定程度后,就需要集群了(水平扩展),针对 服务器集群 ,可以通过负载均衡进行调度,将 任务分配 给不同机器运行,这些任务的逻辑可能是一样的,比如说Nginx集群处理相同的HTTP请求,Mysql多个副库处理相同的Sql查询。

针对水平扩展,当任务达到一定规模和复杂度后,再进行任务分配性能也不能恒定提升,可能需要采取 任务分解 的方式了,将任务划分更小的子任务,不同的子任务再扩展可能就相对简单了,但子任务越多,复杂度可能也会提升,比如现在的微服务。任务分解更多是从软件开发(功能拆解)的角度考虑的,这个和任务分配(负载均衡)不一样。

最后一个水平扩展方式就是分片,针对的是 存储集群 ,这和分布式中间件有关,这也是后续我学习的重点,如果从Mysql角度来看,分库分表只能算是任务分解(根据业务拆分库表)和任务分配(冗余负载均衡)的结合,本身不支持类似Redis这样的存储集群。

一个问题,通过客户端构建的Memcached集群属于任务分配还是任务分解,或是分片?

垂直扩展总有个头,水平扩展可能是业务发展必须要经历的,会花大量的成本,技术实现复杂度也更高,但一旦业务发展起来,那么这些都是值得的。

在专栏中,有个用户留言很精彩,就是高性能和伸缩性的区别,伸缩性首先不是高可扩展,高性能强调处理任务的时间长短,而伸缩性表示随着用户请求规模的变化,在不影响性能的前提下,整个系统是否能够做到弹性伸缩,大白话一点就是微博有明星事件的时候,系统能否自动扩容,而事件下去后,又能够自动缩容。

接下去说说三高之一的高可用,高可用表示“系统无中断执行其功能”的能力,一般用多个9来表示,比如4个9表示一年服务的中段时间不能超过53分钟。

不是说系统可用性越高越好,毕竟有成本和技术复杂度在哪儿呢,在设计之初,根据业务重要性和规模,要对可用性有个大概的预期,对于大公司来说,高可用的服务是其核心竞争力。

那么为什么服务会出现不可用,比如说硬件故障,如果没有集群技术,那么整个服务可能就完全不可用了。如果分层解耦,不同的服务部署在不同的机器上,而机器刚好是单点,那么服务也不可用了。

还有就是软件Bug,按我的经验,很多不可用是因为软件刚上线引起的。不管是硬件还是软件故障,本身这些是不可避免的,既然不可避免,才需要架构设计

单点引起不可用,那么高可用一般是通过“冗余”来实现的。高可用分为三个方面,第一个是计算高可用,相对好解决,比如说DNS指向一个VIP,VIP对应的是一台Nginx服务器,然后后面通过负载均衡算法调度应用服务器,这些应用服务器之间是无状态的,即使某一台出现问题也不会影响服务。当然Nginx本身也要注意其可用性问题。

高可用第二个方面针对的是数据高可用,比如Mysql、Redis如何实现高可用,针对Mysql来说,其主副同步本来解决的是数据备份的问题,现在还可以解决高可用和高性能的问题,但必须注意主副不同步对业务带来的问题,这也是分布式一致性问题的难点。

高可用第三个方面我理解的还不透彻,比如说现在的微服务,客户端可以通过注册中心知道那些服务器可用,从而进行服务调用,属于框架部分的。

在《从零开始学架构》说道,高可用基础是“状态决策”,就是集群之间如何判断服务器出现故障,可以是协商式(一般是主备),独裁式(就是其他机器向一台机器发送状态,由这台机器来决定集群状态,其本身可能是个单点),明主式(Zookeeper)。

在“状态决策”上,如果要使用高大上的解决方案,推荐分布式协调服务Zookeeper,它本质上是一个分布式数据一致性的解决方案,针对高可用来说,可以实现负载均衡,集群管理,Leader选举。

三高之一的最后一个是高扩展,对于高性能和高可用来说,都有很成熟的解决方案和工程实践,但高扩展更向软件开发领域的一个概念,概念众多。

首先什么是高扩展,书中说“为了应对将来需求变化而提供的一种扩展能力,但有新的需求出现,好的扩展性能够让我们做最少的改变,无需重构和重建”。高扩展会带来效率的提高,成本可控,所以非常重要,但在设计的时候又不能过度设计,对于架构师来说,提升扩展性有的时候完全凭借经验。

那么如何实际好的扩展性系统呢?作者认为重要的是两点,第一就是预测变化(业务维度),需要对业务有深入的理解,对业务发展方向有很好的把握,所以说架构师很多是领域方面的专家(DDD领域驱动设计?),警惕的是不能过度预测。第二就是应对变化(技术维度),作者认为是封装(稳定和变化,接口重要性)和抽象(包含和实现)比较重要。

其实我认为关于扩展性,作者是点到为止,因为涉及的知识太多了,比如说面向对象设计,面向对象开发,设计模式,SOLID原则,类图设计,实话实说,我概念上是比较混乱的,就像前面提到的,最近看到一篇很好的文章,能够大概解答我的疑虑,后面会分享一下。

针对扩展性如何落地,有个留言很精彩,认为有两个维度,第一就是使用分布式服务框架(难怪现在微服务如此火爆),第二是分布式消息队列中间件的使用,这也是后续我学习的重点。

今天就先备忘到这儿,极客时间在线阅读形式,相比传统书本来说,很大的一个优势就是留言非常精彩,大家如果想购买,可以扫描下面的二维码,这样能有一些返现。

人人都想学架构(一)

原文 

http://mp.weixin.qq.com/s?__biz=MzAwOTU4NzM5Ng==&mid=2455770962&idx=1&sn=aa9f6ba9fda565c7214c70f0ca0be115

本站部分文章源于互联网,本着传播知识、有益学习和研究的目的进行的转载,为网友免费提供。如有著作权人或出版方提出异议,本站将立即删除。如果您对文章转载有任何疑问请告之我们,以便我们及时纠正。

PS:推荐一个微信公众号: askHarries 或者qq群:474807195,里面会分享一些资深架构师录制的视频录像:有Spring,MyBatis,Netty源码分析,高并发、高性能、分布式、微服务架构的原理,JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源,目前受益良多

转载请注明原文出处:Harries Blog™ » 人人都想学架构(一)

赞 (0)
分享到:更多 ()

评论 0

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址