转载

人人都想学架构（一）

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

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

每一本书都有其可取之处，看完《从零开始学架构》后，简单做了个笔记，从整体上对架构有个印象，这本书内容相对还是比较浅显易懂的，如果说《数据结构和算法还是值得学习》文章中推荐的《数据结构与算法之美》专栏能打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原则，类图设计，实话实说，我概念上是比较混乱的，就像前面提到的，最近看到一篇很好的文章，能够大概解答我的疑虑，后面会分享一下。

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

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

人人都想学架构（一）