<commit_before>---

layout: post
title: 如何学习架构
category: 架构
tags: Architecture
keywords: project

---

## 简介（持续更新）

* TOC
{:toc}

借助[如何学习分布式系统](http://qiankunli.github.io/2018/04/16/learn_distributed_system.html) 得来的经验，当一个知识足够复杂，如何学习它本身就很值得玩味

到目前为止，笔者关于架构的几篇文章或笔记

1. [《软件架构设计》笔记](http://qiankunli.github.io/2019/04/16/architecture_design_note.html)
2. [反应式架构摸索](http://qiankunli.github.io/2019/01/21/reactive_architecture.html)
3. [系统设计的一些体会](http://qiankunli.github.io/2018/09/28/system_design.html)
4. [《左耳听风》笔记](http://qiankunli.github.io/2018/09/08/zuoertingfeng_note.html)
5. [《从0开始学架构》笔记](http://qiankunli.github.io/2018/05/06/architecture_from_0_note.html)

按照许式伟的说法，架构相关的图书大概有几类

1. 架构思维类。 通常从一些著名的架构理论讲起，比如开闭原则、单一职责原则等等。其弊端在于过度理论化，而计算机科学归根到底属于工程技术类，应该实践第一。
2. 设计模式类。 这类一般上来就进入架构的局部细节，每个模式的来龙去脉并不容易理解。就算理解了某个具体的模式，也很难真正做到活学活用。
3. 分布式系统架构设计类。 通常从服务端的通用问题如一致性、高可用、高并发挑战等话题讲起，阐述大型业务系统面临的挑战。这些知识虽然非常有价值，但无法延伸至通用业务架构，对大部分企业的架构实践不具备真正的指导意义。
4. 重构类。 主要讲如何如何改进代码，其实是最实用的一类。但在我看来，一个模块最初的地基是最重要的，基本决定了这座大厦能够撑多久，而重构更多侧重于大厦建成之后，在服务于人的前提下怎么去修修补补，延长生命。

## 架构总纲——纲举目张

语言、数据结构、算法、中间件使用等属于硬的内容，比如容易表述，也容易衡量。而架构设计，系统的“三高”则属于“隐性问题”

1. 因为一个系统设计问题导致研发人力的投入和时间成本的增加
2. 业务确实很复杂，做新功能有沉重的历史包袱

最终技术拖累业务

架构是针对所有重要问题做出的重要决策。很显然，不同公司不同阶段碰到的问题不同，架构所做的事情自然也不一样。

架构的道

1. 对于技术问题，主要指高并发、高可用和一致性方面
2. 对于业务问题，主要指业务的需求分析和业务建模

![](/public/upload/architecture/architecture.png)

|道|术|
|---|---|
|内功心法|外功招式|
|知（理论）|行（实践）|
|问题|答案|

## 系统架构

* 微服务 
* 一个问题在一个进程的多线程间存在，多半也在一台机器的多进程，多台机器的多进程间存在，而解决问题的思路多半是一样的，这也是学习基础的必要性所在。比如[一分钟实现分布式锁](http://www.10tiao.com/html/249/201612/2651959749/1.html)

[谈谈互联网后端基础设施](https://yq.aliyun.com/articles/66115)要点：<commit_msg>[fix]add doc<commit_after>---

layout: post
title: 如何学习架构
category: 架构
tags: Architecture
keywords: project

---

## 简介

* TOC
{:toc}

借助[如何学习分布式系统](http://qiankunli.github.io/2018/04/16/learn_distributed_system.html) 得来的经验，当一个知识足够复杂，如何学习它本身就很值得玩味

到目前为止，笔者关于架构的几篇文章或笔记

1. [《软件架构设计》笔记](http://qiankunli.github.io/2019/04/16/architecture_design_note.html)
2. [反应式架构摸索](http://qiankunli.github.io/2019/01/21/reactive_architecture.html)
3. [系统设计的一些体会](http://qiankunli.github.io/2018/09/28/system_design.html)
4. [《左耳听风》笔记](http://qiankunli.github.io/2018/09/08/zuoertingfeng_note.html)
5. [《从0开始学架构》笔记](http://qiankunli.github.io/2018/05/06/architecture_from_0_note.html)

按照许式伟的说法，架构相关的图书大概有几类

1. 架构思维类。 通常从一些著名的架构理论讲起，比如开闭原则、单一职责原则等等。其弊端在于过度理论化，而计算机科学归根到底属于工程技术类，应该实践第一。
2. 设计模式类。 这类一般上来就进入架构的局部细节，每个模式的来龙去脉并不容易理解。就算理解了某个具体的模式，也很难真正做到活学活用。
3. 分布式系统架构设计类。 通常从服务端的通用问题如一致性、高可用、高并发挑战等话题讲起，阐述大型业务系统面临的挑战。这些知识虽然非常有价值，但无法延伸至通用业务架构，对大部分企业的架构实践不具备真正的指导意义。
4. 重构类。 主要讲如何如何改进代码，其实是最实用的一类。但在我看来，一个模块最初的地基是最重要的，基本决定了这座大厦能够撑多久，而重构更多侧重于大厦建成之后，在服务于人的前提下怎么去修修补补，延长生命。

## 架构总纲——纲举目张

语言、数据结构、算法、中间件使用等属于硬的内容，比如容易表述，也容易衡量。而架构设计，系统的“三高”则属于“隐性问题”

1. 因为一个系统设计问题导致研发人力的投入和时间成本的增加
2. 业务确实很复杂，做新功能有沉重的历史包袱，最终技术拖累业务

架构是针对所有重要问题做出的重要决策。很显然，不同公司不同阶段碰到的问题不同，架构所做的事情自然也不一样。

架构的道

1. 对于技术问题，主要指高并发、高可用和一致性方面
2. 对于业务问题，主要指业务的需求分析和业务建模

|道|术|
|---|---|
|内功心法|外功招式|
|知（理论）|行（实践）|
|问题|答案|

![](/public/upload/architecture/architecture.png)

当你碰到一篇文章，即可place it in context，分析其在架构知识的哪一层

## 系统架构

* 微服务 
* 一个问题在一个进程的多线程间存在，多半也在一台机器的多进程，多台机器的多进程间存在，而解决问题的思路多半是一样的，这也是学习基础的必要性所在。比如[一分钟实现分布式锁](http://www.10tiao.com/html/249/201612/2651959749/1.html)

[谈谈互联网后端基础设施](https://yq.aliyun.com/articles/66115)要点：
{'fraction_non_alphanumeric': 0.15321849501359927, 'fraction_numerical': 0.05439709882139619, 'mean_word_length': 7.552971576227391, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 2, 'lorem ipsum': 0, 'www.': 2, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '2397704', 'n_tokens_mistral': 2678, 'n_tokens_neox': 3050, 'n_words': 127}