前言
在简单学习Golang和C++基础语法后，我需要阅读系统源码，为了更好理解系统架构、系统内部模块交互和不同业务场景下的数据流，绘制一些简单流程图、时序图和系统架构图是有必要的。

主要工具：
process on
ppt
系统架构图
最原始的系统架构图，简单分层展示不同层次的模块，加上基础服务、公共服务和监控服务：






image

加上数据流的系统架构图：






image

流程图
简单业务流程图：






image

加上接口的流程交互图：






image

接口交互图
简单的多个接口交互逻辑图：






image

模块提供的内外部接口和外部依赖：






image

时序图





image

程序流程图
梳理并发程序或复杂逻辑程序时可以会用到：






image

算法图
这部分是用ppt做的，帮助直观理解算法原理，ppt画图的自由度更高

boosting






image



k折交叉验证






image



随机森林






image


总结
作为一个研发菜鸟，在阅读大型系统的源码时碰上了很多问题，很多时候并不是语法层面的问题，反而是因为快速迭代开发和系统的庞大性给我梳理系统架构和模块功能带来较大的挑战。

通过简单绘制系统的架构图、各模块之间的接口交互和时序图等，我可以更加直观地理解整个系统的运作模式，大概就是所谓的磨刀不误砍柴工。

产品架构图通常用于比较复杂的产品项目中，是设计复杂产品时不可或缺的文档之一。在本文中，笔者也向大家介绍一下画产品架构图的流程以及关键点，希望对你有所启发。
一、什么是产品架构图
产品架构图是产品经理用来表达自己产品设计机制的一张概念图：
它将可视化的具象产品功能，抽象成信息化、模块化、层次清晰的架构，并通过不同分层的交互关系、功能模块的组合、数据和信息的流转，来传递产品的业务流程、商业模式和设计思路。
由于产品架构图通常用于比较复杂的产品项目中，目前介绍产品架构图的相关书籍和资料极少(尤其是入门级别的资料很少提及)，却是设计复杂产品时不可或缺的文档之一。
为什么要画？
首先梳理自己对产品方向的判断，思考这张图如何设计的过程，也是帮助你梳理“半年内自己的产品该往何处去、需求应该如何分期和落地、和其他产品的依赖、竞争关系是什么、未来的可拓展性在哪里”等问题的过程。
1. 为技术&运营的输出形成支撑
当这张图被设计出来后，按照产品架构图的结构和路径，项目的里程碑(RoadMap)就可以被清晰的拆解出来，同时项目成员也可以根据这张架构图产出运营计划、技术系统架构方案等强依赖产品方向的方案。
2. 让他人可视化的理解你的产品架构
能较为清晰简单的呈现自己的思路、明确自己的产品边界、指明发展的方向，常用于在项目规划或项目总结中进行演示，帮助不了解你的产品的人快速的建立对你的产品结构、功能、复杂度的认知。
二、何时需要画
建议在复杂项目开始前写：
当你要开始设计一个系统性、完整的需求时，如果跳过画产品架构图的步骤，直接开始画原型、写PRD，有时候很容易发生“改了又改”、“做了一版需求然后又推翻”的情况。如果你的项目已经进行到一半，自己却从未产出过这张图，那么就从此刻开始，按照下文的步骤尝试为自己的产品产出一张产品架构图吧。
三、画前准备
列出问题域
在需求初期，产品经理得到的往往只是一句比较模糊的需求描述，它们可能来自于老板、运营或用户。
直接把这句话作为核心产品功能是不恰当的，合理的做法是先把这个产品所有的问题域列清楚。
“问题域”是指自己的产品能够解决的所有问题的空间集合。从核心需求出发，将所有当前需要解决、未来可能要解决的问题放入产品框架的范围，能够帮助你的产品架构图拥有更高的可拓展性，在后续具备迭代和优化的空间。
以微信AR的需求为例，问题域是这样一个集合：
详细操作步骤：
找到收到的需求中，跟产品形态、产品目标相关的词句，去列出“XX的流程会是什么样”、“XX该怎么达成”之类的问题，直到如果这些问题解决，能够实现核心需求的方向和业务目标。
去逐次寻找这些问题需求被解决的过程中，是否有其他要先解决掉的问题、或者其他跟业务相关的问题能够被解决/改善。
按照层级去罗列出所有的问题，并附上自己的初步回答，从而形成一个初步的、自己的产品能够解决的“问题域”。
四、确定产品方向
在经过问题域的罗列后，你应该能够得到一个模糊的产品方向和功能范围。把这些问题域的答案抽象总结成一个确定的产品需求。
以微信AR的需求为例，根据问题域，我们发现需求不只是扫码组件增加AR识别能力这么简单，整个需求里需要引入广告主的角色，并且需要和腾讯等团队合作。最终得到的产品方向描述是这样的:
1. 详细操作步骤
问题域的环节非常发散，这一步需要回归基础，把模糊的需求补充、拓展和翻译成一个在商业模式和用户体验上能够形成闭环的产品需求。
核心需求确定：我的产品核心解决的是哪批用户、哪个用户需求？
产品目标：如果以一个数字指标衡量我的产品，它应该是什么？
3.用户场景：核心需求基本的产品形态、用户使用的路径是怎样的？
2. 清晰的业务流程
这一步需要根据核心产品需求和问题域的答案，画出简单的业务流程。业务流程是产品设计中常见的图表，绘制方法就不再多做说明。
以微信AR的需求为例，从广告主准备AR互动，到用户在前台使用摄像头参与互动，整个业务流程如下:
五、着手绘制
1. 搭建基础框架
基础的产品框架脱胎于业务流程，但相比业务流程，更加注重产品功能的枚举、功能模块之间的分界。
2. 详细操作步骤
对照业务流程，根据自己设想的产品机制、基本产品形态和用户的使用路径，列出需要的页面&功能&模块等前后端逻辑。
将刚刚得到的多个流程图中所有功能类似或者范围有包含关系的机制/功能放在一起，以模块化的形式形成一张简单的矩阵图。
将明显是同一个产品范围、同一组产品功能的模块放在同一层级，得到一个基础的产品框架。
3. 明确架构分层
一个具备前后台关系的产品架构图至少分为三层：用户感知层(在何种场景下通过何种方式触达用户)、功能模块层(通过哪些功能模块实现产品的核心功能、和哪些外部平台功能有信息交互)、数据层(产品的数据从哪里来、产品的数据沉淀到何处去)。
在上一步进行简单分层后，我们已经得到一个初步框架，但是难免会有分层不明确的问题。此时需要按照两种维度来处理架构图的层级：不同信息层级的边界、同一层级内模块和模块的边界。
4. 处理不同信息层级的边界
架构图的层级表达的其实是信息之间的流转关系，不同信息层级之间一定是有逻辑关系的。
其中用户感知层和数据层通常可以简化为一层(用户端的功能表达往往逻辑简单、数据的来源问题则不是自己产品的核心功能)，而功能模块层则需要按照自己产品的逻辑去将功能模块层内的主要模块变成新的层级。
5. 处理同一层级内子模块的边界
各层次之间虽然相关，但同一层次内的子模块之间一定是互相独立、界限分明的。将解决不同问题的功能拆分成两个子模块，做到一个问题只在同一层解决，避免牵一发而动全身的情况出现。
6. 明确产品间的边界
产品边界对于开发设计系统架构、业务间的合作模式都非常重要。用不同颜色标识清楚产品框架中，各个部分所属产品的边界，通常其中属于自己团队的部分用亮色表示。
7. 加入信息流转机制
产品架构图在表达产品的核心功能外，也应该体现信息流动的路径：当前层级数据的交互形成产品功能，产品功能又产生新的数据，从而推动下一层级的功能运转起来。
如果当前产品的主要使用角色只有一个，则只需要用箭头标明模块间信息流动的方式即可。如果当前产品会涉及的主要角色比较多，则需要用不同颜色的线条将他们和各个模块之间的信息交互关系外化出来。
六、最终检查
一张好的产品架构图，应该具备以下特点：
清晰的模块功能边界
功能经过抽象，做到标准化、互相独立
上下游产品功能边界清晰，架构分层明确合理
具备迭代优化的能力
记得不断根据你的产品的发展情况来更新产品架构图，每次修改的过程对提升产品架构能力的帮助非常巨大。认真完成，才会成功。
本文由 @寄书予影 原创发布于人人都是产品经理，未经作者许可，禁止转载。
题图来自Unsplash，基于CC0协议

1、Core OS是位于iOS系统架构最下面的一层是核心操作系统层，它包括内存管理、文件系统、电源管理以及一些其他的操作系统任务。它可以直接和硬件设备进行交互。作为app开发者不需要与这一层打交道。

      2、Core Services是核心服务层，可以通过它来访问iOS的一些服务。

      3、Media是媒体层，通过它我们可以在应用程序中使用各种媒体文件，进行音频与视频的录制，图形的绘制，以及制作基础的动画效果。  

      4、Cocoa Touch是可触摸层，这一层为我们的应用程序开发提供了各种有用的框架，并且大部分与用户界面有关，本质上来说它负责用户在iOS设备上的触摸交互操作。












Core OS层


该层为最下层主要是mach4.x  BSD  UNIX内核，也就是Mac OS 10操作系统，是一个在硬件上能够执行多任务的UNIX内核。在这一层上，它提供了很多支持例如网络、socket、安全机制、文件系统，这里的API大多数都是C的API不是面向对象的，因为这是UNIX代码，我们一般不在这一层上写代码。







Core Services层


这层开始面向对象了，它提供了很多和底层一样的服务，但是是面向对象的API，还提供socket类、Runtime支持、多线程、集合类(如数组、字典)等。可以把这一层当做是提供面向对象支持的Core OS的封装。










Media层


这一层离硬件还是很近，因为iphone、ipad、itouch根本上是一个多媒体设备，多媒体相关的代码贯穿整个ios，在Core Services以上能看到的API都是关于多媒体的。













Cocoa Touch层


cocoa是mac os 10开发环境的名称，在ios上称它为cocoa touch。所有的按钮、滑动条、视图、导航栏、高层次的多媒体都在cocoa touch上，这是完全面向对象的。

Swift也是独立组件，对系统运行没影响。

 

nova-api是对外的接口。

Glance是独立组件，供 nova-compute 下载镜像使用。 

核心组件：

Scheduler: 根据当前资源使用情况，决定计算节点分布到哪台计算节点上。目前实现很薄，目前已支持插件方式扩展，方便后面可能有采用更复杂算法。

Compute：计算节点，使用虚拟化技术， host 虚拟机

Network:　网络管理，给虚拟机分配网络和管理，使外部 PC 可以可直接访问

Volume：给虚拟机分配额外持久化的存储

运行时系统间交互都是通过异步消息的方式和DB 进行交互

 
运行时图 

管理和使用是走两个通道的。管理必须要经由 nova-api转发过去。而运行时，直接连接计算节点上的虚拟机即可。


 

 
OpenStack架构 

OpenStack的架构示意图和目前已实现情况

 


蓝色是要 openstack概念上的架构图，红色是目前已实现的。

 

部署 

部署时，除了Dashboard 必须部署在 nova-api server 上以外，所有的其它进程都可以部署在不同的机器上。


 

OpenStack提供了基于 Puppet 的自动部署工具。经过简单配置，就可以把各个组件部署到不同机器上。

 

 

OpenStack的镜像创建并没有纳入其职责列表。

你可以使用Ubuntu的已有image (https://help.ubuntu.com/community/UEC/)，或者直接重新自己通过KVM安装  http://cssoss.wordpress.com/2011/04/27/openstack-beginners-guide-for-ubuntu-11-04-image-management/

 
网络模型 

Flat Network Manager, Flat DHCP Network Manager, VLAN Network Manager.

VLAN Network Manager 这种方式适合于共有云。

在私有云方面， IP充足，而且为了方便的互联互通，简单的Flat结构网络比较适合。

OpenStack支持 Floating IPs ,该特性可以方便的通过更改IP来Failover(容错转移）或者迁移。

 
CAAS 

Cluster as a Service: Managing multiple clusters for openstack clouds and other diverse frameworks

OpenStack无法独自满足集群计算的需求。目前有一种方案，把集群计算部署放到 IaaS/PaaS 的下一层，我们称这种解决方案是 CaaS.

当前，在很多机构或者学校，部署了不同的集群解决方案，但是他们使用的频率并不是很高，因此资源利用率不高的情况下，造成了很大的浪费（比如电费， PC）。

     设计目标：

o  每个集群资源都可以动态分配

o  系统隔离性好  

o  集群有足够的性能和容量  

      设计：

o  IaaS/PaaS层与 CaaS 隔离

o  IaaS/PaaS 层可联机扩展

o  CaaS  层的镜像可通过容器有效被处理

o  CaaS  层是通过 webservice提供服务  

o  可通过 VLAN 网络隔离  

o  自动安装


在这个解决方案中是通过 LXC的 方式来实现系统隔离


注：

LXC, LINUX的容器工具，他使用cgroup把系统资源分组进行隔离。

它不需要指令级模拟。因此相对其他虚拟化技术性能更高。

因为他必须以进程运行执行文件的方式，因此不支持windows.


架构图