.. Kenneth Lee 版权所有 2017-2020
:Authors: Kenneth Lee :Version: 1.0
再谈什么是软件架构
“什么是软件架构”，这个主题在这个专栏中已经谈过一次了：
什么是软件架构 - 知乎专栏
其实看你从什么角度入题了，这个问题可以谈很多次。这次我们从分析现有软件的的角度 讨论什么是“软件架构”。我们从这个博客讨论的问题说起：RancherOS架构分析 - 知乎专 栏
下面有人问到：“什么是软件架构？你写的这些知识又是如何获取的呢？”
从我写那个分析的思路上说，我定义软件架构是：所有可以左右软件发展方向的事实的集 合。
我准备引入一个软件，投入一起开发一个软件，我需要看到一个软件会不会把自己给弄死 了，或者它最终会不会走向我期望它走向的方向。这一方面来自这个软件的全部维护者的“ 理想”，另一方面来自这个软件已经进入的现实。所以架构分析，就要弄清楚这些人的理想 和现实，综合判断它是否可以支持我的个人理想的实现。
所以，我分析这个软件，第一反应是它的维护者是如何定义这个软件本身的，这通过看它 的主页就可以了：
.. figure:: _static/container.png
我看到两个关键字：Management和Production。现在我看它卖什么，靠什么赚钱
，公司有多少人，这决定了它的投资模式（实际上这部分我藏了私，我没有放在
博客中，这也是NDA的要求）。
然后我就发现它是个开源项目，所以，我git clone了它的代码（当然我们都知道，开源项 目和一个公司要卖的东西不一定一样）。然后查看它的版权声明，编程语言，代码量等。
到此为止， 我从“理想”角度，对这个软件有了一个基本的认识。在进一步了解软件已经建 成的状态以前，我需要先自行建一个逻辑：如果我来干这件事，我会怎么干：
我简单设想，我会Rebase一个已有的发行版（我很可能选择Debian，因为我熟悉Debian， 而且我可以利用Debian的升级基础来实现我的版本的持续维护），然后我会写一组命令， 用于在Container的基础命令之外执行经常会执行的动作。Debian的安全按一般定制发行版 的方式实现，命令用Python来组织（用Python是因为我熟悉Python，同时它提供了足够的 脚本能力），最后就是我可能会自己创建一个Registry来提供我自己认证的Image服务。
然后我会从这个角度来对它的实现进行对照，这个我可以通过在虚拟机中安装和查看这个 产品来达成。
所以我按它的手册的建议安装了一个系统，首先在它的Host上用tree来看它大部分的文件 分布和文件来源。这样很容易就可以发现如下重要的事实：
它的基础发行版用的是busybox+uclibc，这个，作为一个有发行版组织经验的人，你应 该清楚，这很可能直接可以用ucblic本身的buildroot就可以实现了，而且很容易实现 多版本的支持。唯一的工作量是把docker的命令集成进去。也知道它每次生成一个启动 的iso的工作量有多大了。
然后看看它额外增加的busybox之外的命令的版本和使用的库，就可以知道它是基于 uclibc的工具链进行每个独立编译得到的
然后我们用ps看正常运行的系统的进程表，可以看到Host上提供了什么服务
接着安装两个典型的Image（我装的是CentOS和Ubuntu），一个安装了一个Apache，一 个编译了一个Linux Kernel。大概了解一下它的成熟度和使用的Registry
最后，从源代码最后看一次ros命名的功能和大概组成，通过strace跟踪一两个命名设 计的系统文件和系统调用，就可以知道有什么额外的信息需要了解。
这样之后，能否维护，未来这个方案会如何发展，就有初步的理解了。
顺便说一句，在分析的过程中，我其实还通过mount看了一下它的文件系统layout，对 /etc/hostname被mount到/dev/sda1上非常不理解，所以我花了一点时间看了一下mount的 手册和对应的代码，然后总结成一个独立的描述：mount --bind 可以算是ln一个目录么? 。我手上有无数这种分析，一般我会写在evernote上，但前天正好在机场等飞机，写的时 候手边访问evernote不方便，所以就改写到知乎上了。我举这个例子是说，其实架构师手 边是有大量的分析数据的，但必须能保证这些分析不会随意进入主分析链，避免目标被冲 淡了。所以，你看到一点点的决策或者判断，实际上可能背后都是大量的工作。