视频是在时间上连续的一系列图像帧的集合，是一种没有结构的图像流。我们可以把视频看作一本没有目录和索引的书，那么一幅图像帧就相当于书中的一页。由于视频这部书缺乏目录和索引信息，人们就无法对它进行高效浏览和检索，无法快速阅读。为寻找感兴趣的视频片段，人们只能采取“快进”和“快倒”这种耗时的阅读方式线性浏览。

随着数字视频数据量迅速增加，传统的“线性”浏览方式已远不能满足人们对视频内容的访问和查询需求。用惯了文本搜索引擎的用户越来越希望能在海量视频库中快速找到自己感兴趣的视频片段，因此就需要为视频建立有效的目录结构，以方便查找。一般来说，按照视频内容粒度可以把视频分为多个层次，从高到低依次为：节目、场景（故事）、镜头组、镜头和关键帧。

镜头是指摄像机从打开到关闭的过程中记录下来的一组连续图像帧。镜头边界是客观存在的，可以采用一定的方法自动检测镜头边界。在实际应用中，用户浏览一个镜头中所有图像帧是非常耗时的，因此常用关键帧技术实现快速浏览。关键帧是指代表镜头中最重要的、有代表性的一幅或多幅图像。依据镜头内容的复杂程度，可以从一个镜头中提取一个或多个关键帧或构造一个关键帧。为了在语义层建立视频结构模型，需要对视频进行场景划分。场景定义为语义上相关、时间上相邻的一组镜头，它们能够表达视频的高层次概念或故事等。镜头是组成视频的基本物理单位，而场景（又称故事）则是视频在语义层的单位，通常只有场景才能向观看者传达相对完整的语义。镜头组是一组在时间上相邻并在内容上相似的一组镜头，它是界于镜头和场景之间的一组连续的物理实体，是联系镜头和场景的桥梁。节目则是由时间上有序的场景组成，例如新闻节目、娱乐节目、体育节目、天气预报等。

基于上述的视频内容的结构化分析框架，自动镜头边界检测和关键帧提取技术的研究是视频内容分析中的重要研究课题，也是场景构造的基础。在镜头边界检测之后，就要提取相应的关键帧。提取关键帧的方法有很多，最简单的方法是提取每个镜头的第一帧和最后一帧作为关键帧。更好的方法是根据镜头的视觉内容和运动提取关键帧，甚至可以用拼接方法生成一个全景图作为关键帧。

一旦镜头和关键帧提取出来后，一种简单且直观的方法就是用关键帧的顺序排列来表示或展现视频内容。用户可以通过浏览关键帧序列来了解视频内容，并可根据自己感兴趣的关键帧来选择性播放或下载视频片段。当视频长度较短且内容简单时，少量的关键帧就可以较好地表示整段视频；然而当镜头和关键帧数量巨大时，这种方法对用户检索和浏览来说仍是困难的和繁琐的。例如，一部故事片可能包含数千个镜头和更多的关键帧，如果仅用这些关键帧序列来表示节目内容是没有意义的，因为人们更关心的是故事情节而不是镜头和关键帧。为了使用户更好地访问视频数据库，人们提出了视频摘要技术。顾名思义，视频摘要是对视频内容的高度概括，是视频中最重要、最精彩的总结。如何为视频构造良好的摘要是视频处理和检索中的另一个重要研究课题。目前，对视频摘要的研究主要集中在场景分割上，人们试图通过对视频场景的分析来实现视频摘要。

在视频流的层次性结构建立后，就可以对视频内容进行快速浏览和检索了。在视频浏览中，用户可以通过对视频摘要的浏览来确定是否观看某段视频，并可直接定位到感兴趣的关键帧，从而免去“快进”和“快倒”的烦恼。除了方便浏览外，还应为用户提供高效检索手段。通过检索，用户可以快速查找到自己感兴趣的视频内容。实现检索的关键是为视频内容建立有效索引结构，其中视频片段、关键帧、关键词、目录结构、特定对象（例如人脸、汽车等）、叠加字符、伴音和特定运动等都是建立索引的重要内容。建好索引的视频数据库相当于一个层次式的语义网络，用户可以根据需要采用多种不同的方式提出查询请求，实现多模态的人机查询界面。

视频信息处理和检索技术具有非常广阔的应用前景，目前世界上很多著名的研究机构在研究视频信息检索技术及其应用，并开发了一些原型系统，如UIUC的MARS系统、IBM的CueVideo系统、Microsoft的新闻视频浏览系统、Columbia大学的VideoQ系统以及CMU的IDVLS系统等等。

视频信息处理和检索是一个内容非常广泛的、交叉性很强的研究领域，涉及到多方面关键技术。一个高效的视频处理和检索系统需要由各个处理模块的相互配合，而其中每一个模块的实现都是一项细致的、复杂的工程。从目前的研究来看，要实现真正实用的视频处理和检索系统，还需要做很多工作。相信随着网络技术和多媒体技术的发展，在研究人员的共同努力下，视频处理和检索技术的研究将跨上一个新的台阶。

    进入正题，今天说说硬件防火墙的端口映射配置，以及端口映射的应用。所谓端口映射，就是把“某个IP地址的某个端口（也叫套接字）映射到另一个IP地址的某个端口”，其实和NAT一样，本来都是路由器的专利。但出于加强安全性的考虑，一般现在在内网出口布置的都是硬件防火墙，路由器的大部分功能也能实现。当然了，现在的新趋势是IPS。。。

    时下IPv4地址短缺，一个单位有一两个固定IP就算不错了，要实现内部网多台主机上公网，不用说需要作NAT，把内部私有IP转换成公网IP就搞定了。但如果需要对外发布一个以上的网站或其他服务，或是没有VPN但需要作多台主机（服务器）远程控制，一两个IP怎么说也是不够的，这种时候就需要用到端口映射了（莫急，这就开始说了）。

　一般来讲，防火墙的默认包过滤规则是禁止，如果不做端口映射，外网地址的所有端口都是关闭（隐藏，检测不到）的，不允许从外网主动发起的任何连接（这就是在内网使用某些P2P软件显示“您的外网端口无法被连接”之类信息的原因）。下面结合实际讲讲配置。俺公司两台防火墙，一台天融信一台联想网御，联想网御作外网应用。比如，现有如下需求：

外网ＩＰ地址123.123.123.123，需要将内部网192.168.1.10和192.168.1.11两台服务器上的HTTP服务对外发布。

　外网地址只有1个，外网地址的80端口也只有1个，既然要发布两个HTTP，也就不必（也没办法）拘泥于80端口。我们可以随便选择外网的端口号，比如，指定外网地址123.123.123.123的8080端口映射至内网192.168.1.10的80端口，指定外网地址123.123.123.123的8081端口映射至内网192.168.1.11的80端口。这里，如果没有特殊要求，外网端口的选择是任意的，外网用户只要在IE的地址栏输入“123.123.123.123:端口号”就可以访问相应服务。当然，也可以指定外网地址123.123.123.123的80端口映射至内网192.168.1.10的80端口，这样用浏览器访问时就不用加端口号。

　添加端口映射配置的步骤，各品牌的防火墙不太一样，但大同小异。

　比如，天融信没有专门的端口映射配置，直接在NAT中配置即可。进入防火墙引擎－地址转换－添加配置，源area选择接外网的以太网口，源地址选any（有特殊需要的可以做源地址限制），源端口为空即可（即允许源端口为任何端口）；目的area为空（空即任意），目的地址选择外网地址123.123.123.123（需预先定义），服务选择TCP8081(或TCP8082，服务也需要预先定义)，下面目的地址转换为192.168.1.10(192.168.1.11)，目的端口转换为80（HTTP），启用规则即可。

　网御直接有专门的端口映射配置，比较好理解，添加规则，选择源地址（any，或自定），对外服务（8080或8081），源地址不转换，公开地址选外网地址（123.123.123.123），内部地址选择内网服务器地址（192.168.1.10或192.168.1.11），内部服务选80，启用规则即可。

　至此，我们实现了两条端口映射规则：123.123.123.123:8080--192.168.1.10:80和123.123.123.123:8081--192.168.1.11:80。

　同理，我们如果想让p2p软件在内网能正常工作的话，即让外网用户能连接p2p软件的监听端口，也需要作端口映射。比如，如果内网192.168.1.13运行Bitcomet监听22345端口，显示黄灯阻塞，我们作一条端口映射规则123.123.123.123:22345--192.168.1.13:22345，就可以变绿灯了，电驴也是一样。

　下面谈谈端口映射配合远程桌面的应用。以前公司没有VPN，为了能在家远程办公通过远程桌面访问我的机器192.168.1.15，于是通过端口映射作123.123.123.123:3389--192.168.1.15:3389来实现，这样在家里运行Windows自带的远程桌面（其实远程控制软件很多，但为了能在紧急情况时随便找一台能上网的机器就能用，所以还是选用系统自带的），输入地址123.123.123.123就可以远程登陆到我公司内网的机器。但3389端口只有一个，这样就只能我自己用。后来发现，在远程桌面中输入IP地址加端口号也可以。这样就好办了，作123.123.123.123:9991--192.168.1.15，然后在家运行远程桌面，输入123.123.123.123:9991，就可以登陆我的机器；再作123.123.123.123:9992--192.168.1.16等等，就可以实现多人通过一个公网IP远程桌面访问自己的机器，没有VPN远程办公也很方便。但要注意这样有一定的危险性，因为家里一般用ADSL，IP地址不是固定的，所以作规则时源地址一般支能选any，即允许任何人连接9991端口，不过问题一般不大。

　综上，端口映射可以将内网的任何服务发布到外网地址的任何端口，非常方便，灵活运用的话对网管工作很有帮助。但切记，这种方法有一定的安全隐患，需慎用，最好在地址、端口、连接数、带宽等各方面做好限制，以将危险减至最低。累死我了，下班了，回家吃饭。。。

新浪是怎么成功的？

1、  抓住了中文信息资源缺乏的历史初期网民对信息资源的整合需求。

2、  一个技术背景的管理领袖但是却绝对没有一般技术人员的狭隘性

3、  历史机遇，抓住了发展时期的历史性机遇

4、  足够的股份制企业的运营资源使得能够等到互联网免费到增值收费的那一天

搜狐是怎么成功的？

1、  主要是张朝阳的对公司的掌控，更重要的是美国商业文化在中国的成功结合实施

2、  跟在新浪后复制而幸运的是中国市场很大，网民数量增长空间足够两家资讯门户成长

3、  足够的发展资源

4、  分类搜索迎合了该阶段的网民需求

网易是怎么咸鱼翻身的？

1、  网易是丁磊一个人的

2、  抓住了短信、抓住了网游，年轻网民的需求

3、  早期的发展积累了大量的人气是其咸鱼翻身的重要保证

TOM是怎么上来的？

1、  资本的力量，具有近乎无限的资源以及资源的整合能力，收购再收购

2、  收购了163.net，绝对是经典的“豪夺”，否则，哪里来的网民占有率

3、  不同于现有领先者的发展路径（不跟你现有大门户正面竞争，你做短信，我也做，但我更注重做IVR，没有产品，咱就收购，收购。。。.），很聪明的发展策略。如果没有那些收购来的公司，TOM就是一个163.net。当初，李财神准备招股书那会儿，TOM的主页上就只有一个LOGO呢。

腾讯是怎么成功的？

1、  抓住了网民中文即时通讯的需求，用户的使用习惯成就了藤讯的成长

2、  对手长期忽视（就像IBM忽视了MS的成长，YAHOO忽视了Google一样），侥幸，否则。。。

3、  移动增值的业务发展抓住了

盛大是怎么成功？

       就不说了。其实要说的就只有陈天桥了，因为网游最早的是联众，而当联众初卖出去1000万，创始人还高兴得不得了，唉。。。

同样是程序员，同王志东比为什么差别就那么大呢？

看到没有，都是成功抓住了网民的需求。

       在日常的开发中， 作为一个程序员， 很多东西已经没有必要再重新开发了， 可以直接拿过来使用， 毕竟21世纪都已经过了N年了。我们没有必要重新发明轮子(不可否认发明轮子的过程可以学到很多东西，我就是这么走过来的)。

       下面结合自己多年的开发经验， 想到哪里写到哪里， 希望对新人有一定的帮助。

        一、网络

              网络库必须掌握 ACE 和 libevent， 一个是重量级的网络库， 一个是轻量级的网络库。仔细想想，现在那个程序不用网络啊。不懂网络， 你将寸步难行啊。 熟悉这两个开源库的前提是你必须懂socket的原理， 给大家推荐的好书就是 《UNIX网络编程》，看懂这本书就可以了， 其他的什么《windows网络编程》这些都不用看， 因为网络编程，你学会了伯克利的套接字， 你就可以在任何平台上进行网络编程了， 不需要学什么windows下的网络编程， 因为windows下的网络也是从伯克利套接字搞过来的， 如果你学习《windows网络编程》， 那么你那天在linux，unix下进行网络编程，你还得在学习一下。没有那个必要。

       二、数据库

             数据库嘛， 开源的Mysql和开源的PostgreSQL只要懂其中一个就可以了， 商业数据库在掌握一个Oracle就可以了，文件数据库掌握 sqlite。 不过请大家注意， 不要被上面数据库名字给迷惑了， 数据库的本质是SQL语句， 一定要懂数据库的基本原理，熟练应用SQL语言，懂数据库的优化，存储过程等。数据库的原理搞懂了， 拿什么数据库过来都轻松掌握， 就不会在乎是Mysql还是Oracle了。

       三、日志操作

             日志操作推荐大家熟悉 log4cpp这个日志库， 支持多线程， 日志重定向到网络等都有， 反正你能想到的日志的功能， 都有。

日志嘛，一个是方便查找问题， 方便记录程序运行的一些情况。这是必须的。

       四、管理后台

             众所周知， 写程序是给其他人用的，不是自己用， 所以在程序的易用性上，多给对方提供一些可以直接查看的管理界面， 显得分成重要。为程序提供一个web的管理界面，方便用户登录上去查看程序的各种信息， 很有必要。

             我这里有一个方便的web后台管理的http实现， 可以方便的集成到应用程序中。在IE里面输入监听的端口，就可以查看程序的状态。代码还没有仔细整理。有需要的弟兄可以给我留言， 给大家发。

       五、读取配置文件

             所有的程序都必须有配置文件， 方便配置一些项目， 为程序提供灵活性。 所以写程序，必须有读取配置文件的封装类。

       六、内存池

             所有的进程都需要分配内存， 对C/C++来说， 分配和管理内存是已经很有挑战性的工作。

             给大家推荐 nedmalloc 这个开源的内存池库。nedmalloc是一个跨平台的高性能多线程内存分配库，很多库都使用它。

       七、缓存库

             众所周知， 缓存库用得最多的就是 memcache 了。在做数据库开发的时候特别有用。

       八、脚本

             脚本是一个很有意思的东西，很多功能，其实我们只要写个脚本就可以完成，代码量少，开发速度快。

             必须掌握的脚本，比较通用的要算 perl 了， 很古老的语言，但是功能太强大了。 我可以保证的说，.net，java能干的工作，肯定可以让perl来干。 C能干的， perl不一定能干。 perl作为linux， unix的系统集成的脚本语言，必须学会。

             lua 语言， 这个语言， 在游戏行业用得比较多。不推荐学。

             python 脚本， 功能很强大， 推荐学。

        上面这些是所有程序都会用到的比较通用的功能。

        在不同的应用领域， 需要掌握不同开源库， 比如搞游戏开发的， 可能需要掌握开源的UI库CEGUI, 开源的3D引擎OGRE等。

搞分布式开发的可能会有分布式的文件系统库等。

        今天就为大家介绍到这里， 慢慢完善慢慢补充。

http://blog.csdn.net/langeldep/article/details/6293655

概念

路由

路由（routing）就是通过互联的网络把信息从源地址传输到目的地址的活动。这里需要明确两点：

路由不等于路由器，很多人一提起路由，就想到路由器，实际上这是不对的。路由器仅仅作为路由的一个硬件实现，同样，我们还可以借助一些软件实现“软路由”。

既然路由是通过互联的网络把信息从源地址传输到目的地址的活动，那么存在着从源地址到目标地址的“路径”，至于这个“路径”是如何找到的，可以通过一系列算法得到动态路由，或者直接手动设置静态路由。

我们平常设定的“网关”，实际上就相当于手动设置的静态路由。

路由器

路由器(router)是路由的实现者，它工作在OSI第三层(网络层)上、具有连接不同类型网络的能力并能够选择数据传送路径的网络设备。路由器有三个特征：工作在网络层上、能够连接不同类型的网络、能够选择数据传递路径。它能理解数据中的IP地址，如果它接收到一个数据包，就检查其中的IP地址，如果目标地址是本地网络的就不理会，如果是其他网络的，就将数据包转发出本地网络。

TTL

TTL（Time To Live）是IP协议包中的一个值，它告诉网络路由器包在网络中的时间是否太长而应被丢弃。有很多原因使包在一定时间内不能被传递到目的地。例如，不正确的路由表可能导致包的无限循环。一个解决方法就是在一段时间后丢弃这个包，然后给发送者一个报文，由发送者决定是否要重发。TTL的初值通常是系统缺省值，是包头中的8位的域。TTL的最初设想是确定一个时间范围，超过此时间就把包丢弃。由于每个路由器都至少要把TTL域减一，TTL通常表示包在被丢弃前最多能经过的路由器个数。当记数到0时，路由器决定丢弃该包，并发送一个ICMP报文给最初的发送者。

NAT

NAT，网络地址转换（Network Address Translation），是通过将专用网络地址（如企业内部网Intranet）转换为公用地址（如互联网Internet），从而对外隐藏了内部管理的 IP 地址。这样，通过在内部使用非注册的 IP 地址，并将它们转换为一小部分外部注册的 IP 地址，从而减少了IP 地址注册的费用以及节省了目前越来越缺乏的地址空间（即IPV4）。同时，这也隐藏了内部网络结构，从而降低了内部网络受到攻击的风险。

在一个典型的配置中，一个本地网络使用一个专有网络的指定子网（比如192.168.x.x或10.x.x.x）和连在这个网络上的一个路由器。这个路由器占有这个网络地址空间的一个专有地址（比如 192.168.0.1），同时它还通过一个或多个因特网服务提供商提供的公有的IP地址（叫做“过载” NAT）连接到因特网上。当信息由本地网络向因特网传递时，源地址被立即从专有地址转换为公用地址。由路由器跟踪每个连接上的基本数据，主要是目的地址和端口。 当有回复返回路由器时，它通过输出阶段记录的连接跟踪数据来决定该转发给内部网的哪个主机；如果有多个公用地址可用，当数据包返回时，TCP或UDP客户机的端口号可以用来分解数据包。对于因特网上的一个系统，路由器本身充当通信的源和目的地址。

我们通常使用的路由器一般都自动集成了NAT。

LAN路由

Windows Server 系列，可以在路由和远程访问中设置LAN 路由，这仅仅是路由的一个实现，不存在NAT功能。

最初规划

最初，我采用最简单的路由器组网方式，来组建实验室网络：在网络中接入路由器，设置路由器WAN端IP地址为222.200.176.144，对内网段为10.96.32.*。这时，内网地址能轻松访问外网机器，但是，外网机器却不能访问内网机器：

执行tracert命令，结果如下：

这说明，tracert试图通过默认路由（222.200.176.254）来查找路径，这显然到达不了目标。

既然我们的内网是通过222.200.176.144这个IP连接互联网的，因此我需要在我的机器里手动添加一条静态路由，告诉网络，如果访问10.96.32.*段的东西，直接从222.200.176.144这个地址寻找就好了，不要麻烦222.200.176.254。

route add -p 10.96.32.0 mask 255.255.255.0 222.200.176.144

在执行tracert，结果……

#@￥#@！￥@

这是为什么呢？

请教某网络牛人，得到答案如下：

路由器上是做了NAT的，当信息由本地网络向因特网传递时，源地址被立即从专有地址转换为公用地址。由路由器跟踪每个连接上的基本数据，主要是目的地址和端口。当有回复返回路由器时，它通过输出阶段记录的连接跟踪数据来决定该转发给内部网的哪个主机。这就意味着，NAT和路由冲突！或者说，路由器下的网络，只允许内网主动连接外网，不允许外网直接访问内网。

解决办法一

既然知道原因，就寻求解决方案，牛人给出的方案有两个：

1. 取消路由器的NAT功能，改用CCProxy之类的代理提供内网机器连接互联网。
2. 在路由器上开设端口映射。

不过，以上两个方案都是无法接受的：CCProxy共享版只支持有限的客户端，而且，对于某些不支持代理服务器的软件，使用该方案无疑断送了这些软件上网的可能！至于第二种方案，很多服务所使用的端口是不确定的（例如FTP的被动模式），根本无法一一设定这些端口。

添加双网卡服务器

既然上述的两个解决方案都出局了，还有其他的途径吗？这个问题如鲠在喉，不吐不行。为此我在网上查了些资料，终于想到了一个可行的解决方案：既然外网机器无法通过路由器（222.200.176.144）访问内网，那么是不是可以开辟另一条路呢？于是我在内外网间增加一台Server 2008服务器，该服务器有两块网卡，一块接入外网（222.200.176.148），另一块则接入内网（10.96.32.148）。同时，在路由和远程连接中添加“LAN路由”：

在本机的静态路由修改为：

route add -p 10.96.32.0 mask 255.255.255.0 222.200.176.148

再执行tracert，结果：

再度 #@￥#@！￥@

这是为什么呢？

牛人联系不上，只好自己解决。从上图tracert的记录，数据包到了222.200.176.148，就不知道该如何发送到目标了。按理说，在222.200.176.148的机器上，开启了LAN路由服务，应该没什么问题啊？百思不得其解。

不是办法的办法

最后，只能采用以下方案，暂时解决了问题：

在内网的机器上添加一条静态路由，指明：通过IP10.96.32.148访问222.200.176.*网段：

route add -p 222.200.176.0 mask 255.255.255.0 10.96.32.148

尝试一下在本机tracert 10.96.32.144，奇迹般的可以了！

最后的网络拓扑图如下：

小节

我在内网和实验室外网间，设置了两个节点——路由器和部署了LAN路由的双网卡服务器——如果内网的机器想访问Internat（非实验室外网），则以路由器为网关，进行网络地址转换。如果内网机器想和实验室外网互联，则通过双网卡服务器进行地址交换。在一定程度上解决了NAT和LAN路由不能共存的问题。

以下内容发表在8月份的InfoQ中文站电子刊物《架构师》中，主要谈到了我对架构师这个角色的一些理解与认识，有兴趣的朋友也可以留言，我们共同探讨这个话题。

架构师是一个项目组的灵魂人物，他决定着整个系统的技术选型、整体架构以及模块划分，同时还可能担当与领导层的沟通角色，从某种意义上来说，架构师在很大程度上决定着项目的成败与否，正所谓火车跑得快，全靠车头带。

很多优秀的架构师都是从一个优秀的开发人员转变过来的，但优秀的开发人员未见得都能成为合格的架构师。与架构师相比，开发人员所需担当的任务相对狭隘的多，其最大的目标就是编写出精良的代码、做好充分的测试以及撰写高质量的文档等；而架构师所要面对的则相对宽泛得多，除了过硬的技术之外，还需要有良好的表达能力，同时还要有宏观的驾驭整个系统的能力。

有人曾说过，20几岁的编程天才好找，但30多岁的优秀架构师难寻。架构师何其难？除了敏锐的洞察力之外，我认为一个好的架构师必须具备如下几方面的素质：

A． 过硬的技术能力。有人说架构师就不需要编写代码，只需设计整体架构就行了。但我认为这是很片面的，试想一个人如果长时间不写代码，他还能具备持续的技术敏感度么？当然了，这里所说的写代码并非一般开发人员的行为，而是让自己保持住对代码的感觉。还有人说架构师不一定是技术高手，这一点我很同意，但他一定是个优秀的开发者。

B． 良好的沟通能力。这一点尤为重要，因为架构师需要与项目组的开发人员以及领导层不断交换意见，向对方传递自己的设计意图与思想，没有良好的表达与沟通能力是很容易出现问题的。这一点在沟通方式并非母语的企业中尤为明显。

C． 良好的软件工程素质。虽说架构师不是项目经理，但我认为他需要对软件开发过程有清晰明确的认识，这里的开发过程是个泛指，也许是RUP，也许是XP，是什么无所谓，但这种工程素质是每个优秀架构师必备的品格之一。

D． 宽广的知识领域。架构师的眼界一定要开阔，绝对不能局限于眼前的小范围事务，否则极易出现“鼠目寸光”的后果。这就需要架构师不断学习，这里的学习既包括技术上的，同时也包括业务上的以及沟通上的。

E．  领域知识。架构师务必对自己所从事的业务领域有深刻的认识，他未必要成为业务专家，但他一定要对业务知识有深刻的理解。很难想象经常从事金融领域项目的架构师能轻松设计好电信领域的项目架构。知识需要积累，业务也是这样的。

F．  处理系统非功能性需求的本领。架构师尤其需要对系统的性能、容错、并发等非功能性需求方面有独到的认识与解决办法。一个项目到了后期，往往都是这些问题成为整个项目的瓶颈，这时架构师就要发挥其优势了。

架构师之路是崎岖的，充满了荆棘与挑战，但这却是无数开发者的梦想。架构师是多项技能与素质的综合体，每一位以此为目标的开发者都需要在平日的工作中不断提升自己，在这里我衷心的祝愿架构师这个梦想能照进每一位有心人的现实。