【话题讨论】发现架构之美：修炼架构师的平衡之道（获奖名单已公布-2014-7-15）

fengzhanhai

好活动，值得期待

陌路巨额投入

以前读过《架构之美》这本书，这本书详细的说明了架构的特点与组成。。。当时受益匪浅啊。。对于这个活动，当然是不能错过啦。。。支持支持。
1.“虚幻”的架构常常让人觉得它有很多玄妙之处，也许是因为它难以落在纸上，那架构到底是什么？它的主要表现形式是什么？有人说是图，您赞成吗？
     
     架构是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。 软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。在面向对象领域中，组件之间的连接通常用接口来实现。 软件体系结构是构建计算机软件实践的基础。
   说是图，个人感觉这个只能跟绘图员画图的基础一样，是建筑师设定建筑项目的设计原则和目标。。一个软件架构师或者系统架构师陈述软件构架以作为满足不同客户需求的实际系统设计方案的基础。对于这个看法，个人不是很赞同，毕竟架构的模式有很多种。。。

2. 架构是一个过程，而非一个结果，真正的架构师会投入到系统的内在结构、规律、原则和逻辑的过程中，美丽的架构都有哪些特性？请举出一些架构案例。
   个人认为待构建的对象或系统必须具有以下特征：也就是美丽的架构必须具有的特征：
    1.具备客户要求的功能。2.能够在要求的工期内安全地构建。3.性能足够好。4.可靠的。5.可用的，并且使用时不会造成伤害。6. 安全的。7.成本是可以接受的。8.符合法规标准。9.将超越前人及其竞争者。
   例如：我们将计算机系统的架构定义为一组最小的特征集，它们决定了哪些程序将运行，以及这些程序将得到什么结果。我们从来没有看到过一个复杂系统能够很好地满足上述特征。架构是一种折中—决定改进其中一个特征常常会对其他特征产生负面影响。每种结构都由各种类型的组件及其关系构成：它们如何组合、相互调用、通信、同步，以及进行其他交互。组件可以是建筑中的支架横梁或内部腔室、交响乐中的旋律、故事中的章节或人物、计算机中的CPU和内存、通信栈中的层或连接到一个网络上的处理器、协作的顺序过程、对象、编译时的宏、构建时的脚本。还有每个学科都有自己的一套组件和组件间的相互系。

3.优秀的架构师需要当架构师创建软件系统的架构时，重点应该关注什么？

    架构师从事高层次的开发构架工作。必须对开发技术非常了解，并且需要有良好的组织管理能力。可以这样说，一个架构师工作的好坏决定了整个软件开发项目的成败。优秀的架构师需要当架构师创建软件系统的架构时，应该重点关注：1.推动主要的技术决策，并最终表达为软件构架2.确定和文档化系统的相对构架而言意义重大的方面，包括系统的需求、设计、实施和部署等“视图”3.确定设计元素的分组以及这些主要分组之间的接口4.为技术决策提供规则，平衡各类涉众的不同关注点，化解技术风险，并保证相关决定被有效的传达和贯彻这些方面。。。
   以上观点仅作为个人看法。。。说的不好请大家不要见怪。。。互相交流。。

action08

1.“虚幻”的架构常常让人觉得它有很多玄妙之处，也许是因为它难以落在纸上，那架构到底是什么？它的主要表现形式是什么？有人说是图，您赞成吗？
所谓架构，还是要看工程师的技术悟性了，因为这两个字难以描绘。
工作中也碰到不少所谓的架构师，凭着头衔在公司拿不低的薪水。我觉得架构师是高级技术工种的代名词，是一个工作上对公司领导下对普通职员都负责的职位，没个硬的技术功力摆在哪里是不行的，甚至人品都不能太差。那些就凭画两张图，就可以算是架构师的，评级也来得太容易了吧？？是不是公司领导的关系户，还是什么皇亲国戚么？？？


2. 架构是一个过程，而非一个结果，真正的架构师会投入到系统的内在结构、规律、原则和逻辑的过程中，美丽的架构都有哪些特性？请举出一些架构案例。
首先架构是一个有深度的名词，为了得到一个结果，在整个工作中间，过程环境都有参与深入工作的实际经验或能承担工作的潜力。如果工作有一两处短板，对于架构师而言，或许不算什么缺点；可如果处处都是短板，是不是太愧对系统“架构”了？？

举例lamp coder的教程吧，其实画图在书中的第一章节就已经开始培训给新coder了。比如php是运行在apache cgi的，还是作为一个模块，然后怎么连接mysql的，里面讲的全是图。或许对一个初学者而言有点难头晕，在预览全书才会发现，图只是一个够格软件工程师的基本功而已。实际工作还有更多问题等着我们去解决。
真正的架构师，水平应该属于资深工程师吧，会用已有的技术经验，提出远见可行的路线，来帮助整个项目组“偷工减料”，少走弯路。

3.优秀的架构师需要当架构师创建软件系统的架构时，重点应该关注什么？
可行性，而不是纸上谈兵，高谈阔论。因为系统架构出来后，要能做好，能对公司负责，最后让公司挣钱养活大家。这些都是很现实的问题。
工作中碰过不少有不切实际想法的架构师，完全不考虑自己的技术实力，最后让公司项目处于失控状态。


4.双十一的秒杀战役中，一个购物网站要在一天处理完成超过1亿笔的交易，淘宝网采用什么技术架构来实现网站高负载？
问lvs作者，在tb当总裁。后面肯定少不了nosql的说


5.对于Web服务器来说，不管是Apache、IIS还是其它的Web服务器，图片是最消耗资源的，对社交媒体尤其如此，从国外的Facebook和Twitter，到国内的微博微信，这些大型网站在图片处理上采用了什么策略？
图片，附件，还有视频文件都是资源消耗的大户。目前技术方面能推荐的策略，就是在不明显降低用户视觉体验的同时采取有损压缩，但是所有的业务线都要这样做，感觉代价蛮大的。

目前很多大型网站上都是将请求分离到独立的服务器，以降低主web server压力并有着更好的响应速度。
吐槽一下，现在的网站速度还是慢，特别是tb看商品的页面。不清楚是浏览器性能差，还是网速差，还是网站那边不够给力。我现在上网不的不装adblock plus

rh_linux

1.“虚幻”的架构常常让人觉得它有很多玄妙之处，也许是因为它难以落在纸上，那架构到底是什么？它的主要表现形式是什么？有人说是图，您赞成吗？
   架构是一种和协

2. 架构是一个过程，而非一个结果，真正的架构师会投入到系统的内在结构、规律、原则和逻辑的过程中，美丽的架构都有哪些特性？请举出一些架构案例。
   架构一定有一个易懂性存在

3.优秀的架构师需要当架构师创建软件系统的架构时，重点应该关注什么？
   我不是什么优秀的架构师，我自己在设计银行系统时一般考虑以下：以超市这种简单的POS系统为例，
   a) 项目周期
   b) 项目预算
   c) 项目人员或者说开发人员素质
   d) 银行人员（简称行方人员或甲方）素质，包括人品及技术
   e) 需求的复杂度
   d) 每一环节的功能合理性，效率
   f) 后续功能扩展

4.双十一的秒杀战役中，一个购物网站要在一天处理完成超过1亿笔的交易，淘宝网采用什么技术架构来实现网站高负载？
   其实1天1亿的交易量不算不什么，难的是1秒钟要处理50万并发交易才是真正的挑战

5.对于Web服务器来说，不管是Apache、IIS还是其它的Web服务器，图片是最消耗资源的，对社交媒体尤其如此，从国外的Facebook和Twitter，到国内的微博微信，这些大型网站在图片处理上采用了什么策略？
   我主要做C，对WEB不了解

tomac_cu

2. 架构是一个过程，而非一个结果，真正的架构师会投入到系统的内在结构、规律、原则和逻辑的过程中，美丽的架构都有哪些特性？请举出一些架构案例。

凡事都有两个层次，形式与内容。
架构就是研究的形式也就是名，也就是能力，而编程就是研究的内容也就是实，也就是实力。
在宗教上有唯心和唯物。在架构时也会有两个偏差，唯名和唯实，这其实就是偏执。
或觉得名是第一，也就是觉得系统的潜力是架构的重点。
或觉得实是第一，也就是觉得系统的现有能力是架构的重点。
中国文化强调的不偏不倚中庸之道。好的构架就是让名实相符。

很多情况下，好的架构，可以满足项目的不断发展。不良的架构，让你有实力发挥不出来。所谓美丽的架构就是平衡的架构，把瓶颈点尽量提高。
比如数据库的位置就是架构中最纠结的部分。

在项目初期，成本是问题时，应用和数据库在一起，是一个好的物理架构。
随着压力不断提升，把数据库单独出来，变成一个合适的架构。
压力继续上升，静态数据和动态数据的分开了
还在上升，数据库单机不能满足了
还在上升，简单数据库集群不够了，把读和写分开了
还在上升，LVS不够用了，多IP的负载均衡加上来了。
还在上升，更多的使用内存数据库了。
还在上升，只能升级到云计算了
还在上升，只好自己写出专用的云计算了

那是不是一开始就上自己的专用云计算框架呢？业务部门说傻13，你两个月才能变更一个需求，公司被你们it搞死了！

所以好的架构就是够用，略微先进一步的。
好的架构就是钱花的不多，以后数据还能复用的。
好的架构就是业务部门提出的需求，在最短时间内就能实现的。
请记住，绝大部分公司不是研发为主的，是要生存是要盈利的，是要和时间赛跑的。
把时间放在理论上的人，也许在未来会成功，但这不是现在的中国企业所能承担的。
现实的电工们，放弃你的梦想吧，只要把工作做好，少加班，多泡妞。
工作为了生活，绝不要让工作压迫生活，这才是人生的好的架构。
树欲静而风不止，子欲养而亲不待。这样的人生，不是好的架构。
行善和行孝是不能等的，给自己时间去行善，给自己时间去行孝，这才是好的人架构。
所以好的架构就是工作生活两不误（兴趣除外）

txdgtwpv

1.“虚幻”的架构常常让人觉得它有很多玄妙之处，也许是因为它难以落在纸上，那架构到底是什么？它的主要表现形式是什么？有人说是图，您赞成吗？

架构是中大型项目中各个实体的组织结构，它本不应该虚幻或者玄妙，但是因为它不像算法，更不像代码，你很难用数学精确地证明“最优”架构，也不能用丰富的经验保证“完美”架构。架构之所以飘忽，是因为现实的残酷，是因为需要考虑的变量太多。如果你假定大量变量永远不变，那这个架构缺乏灵活性，如果你假定只有很少变量永远不变，那这个架构又变得复杂而且多出很多边界条件。

我不赞成架构用“图”来表示。虽然我们看到的很多架构是用图来展现的，但是用图来表示架构就将架构局限为了一种表面的形式。我去年参加sacc 2013的时候，就有很多架构为了画图而画图。本来是简单直接的优良架构，为了能在“图表”上显得高大上，硬是把一个模块拆成多个，一条连接拆成多条。这种图/PPT导向的架构设计，就如果设计模式导向的代码开发一样。

我认为，架构的体现是一种天然的、符合直觉的体现。大部分时候你甚至不应该感受到它带来的约束。对于功能纯粹单一的项目，揉成一团的组织并不一定是坏的架构，对于功能繁复的项目，架构的组成也一定应该是独立自治的模块以最少的连接组成的。

总之：不要过早优化，也不要惧怕演进

2. 架构是一个过程，而非一个结果，真正的架构师会投入到系统的内在结构、规律、原则和逻辑的过程中，美丽的架构都有哪些特性？请举出一些架构案例。

架构是持续演进的过程，没有最好的架构，只有最适合的架构。功能和需求并不是一成不变的，那么架构也应该随之演进。拿捏好架构的“活在当下”和“拥抱变化”是架构师是否优秀的重要考察能力。

架构师需要从一团乱麻中将功能和逻辑逐渐分离开来，优良的架构一般具有以下特点：

(1) 模块职责清晰明确。每个模块的功能都是纯粹的，也不会有多个模块实现相同的功能。模块的内部逻辑应该尽可能少地暴露出来。

(2) 模块间调用简明，符合相同的规范。横向的调用依赖平台无关的接口（非计算密集需求应考虑RESTful接口），纵向的调用使用形式一致的API。只要接口不变，模块的内部变动应该对接口无感知。

(3) 模块内部的子模块设计。模块划分的层次并不是只有一层，当模块变复杂时，一个模块也可能变成多个模块。在对单个模块进行设计时，同时也要把整个模块当作系统来考虑。

以OpenStack的演进为例。OpenStack在早期版本中就十分注重逻辑的划分，nova、swift本身都是自治可自由替换的模块，它们提供相似的RESTful接口。nova内部的nova-image, nova-network, nova-volume也随着系统的复杂性提高，非常轻便地就从nova中分离出来形成新的一级模块。

3.优秀的架构师需要当架构师创建软件系统的架构时，重点应该关注什么？

(1) 扩展能力。最好能平行扩展，即在设计时要尽量保证无状态和状态的中央控制。

(2) 容灾能力。要保证服务的7x24小时运行，可以参照zookeeper和s3等系统。数据的冷热备份更是重中之重。

(3) 模块的划分与模块间的通信。模块的可替换。

(4) 收集一切可用数据。

(5) 不要重复造轮子。积极融入生态环境。

(6) 架构到代码都要清晰、直接、可读。

4.双十一的秒杀战役中，一个购物网站要在一天处理完成超过1亿笔的交易，淘宝网采用什么技术架构来实现网站高负载？

首先是对web服务功能的分离：接入功能、逻辑调度功能、数据服务

然后分别对这几个部分进行细化的设计。

接入上使用lvs等负载均衡工具，将涌入的流量分摊到海量的逻辑服务器

逻辑服务器无状态，只对请求进行处理，更新数据服务，反馈请求结果。逻辑服务器可能也划分成了多种功能纯粹的服务，通过message queue或类似的方式来解耦。

数据服务包括经过精心优化的MySQL/Oracle数据库，以及memcache等缓存服务


5.对于Web服务器来说，不管是Apache、IIS还是其它的Web服务器，图片是最消耗资源的，对社交媒体尤其如此，从国外的Facebook和Twitter，到国内的微博微信，这些大型网站在图片处理上采用了什么策略？

对于流量小、用户少的web服务来说，把图片和静态文件当作同一种资源处理即可。一量流量上来了，图片往往就成为整个系统的瓶颈。

在海量服务上，图片服务独立成单独的服务一般是靠这几个角度来优化组合的：

(1) 后端存储/文件系统层面，使用大量的后端存储来模拟成一个巨大的存储器，每个图片保留多份，防止部分存储崩溃，同时也可以做到就近读取。有些公司甚至开发专有的文件系统来索引图片文件。比如淘宝的tfs的目录结构只有一层，即目录下就是所有的淘宝图片文件。

(2) 后端缓存，对于热点图片缓存起来，用于快速读取图片信息。

(3) cdn前端缓存，建立cdn节点，用户甚至可以直接在家门口就获取到图片，对系统负载完全无压力。

(4) 图片压缩。减少图片尺寸，使用更节约的图片压缩算法。

hiyachen

3.优秀的架构师需要当架构师创建软件系统的架构时，重点应该关注什么？
架构与软件系统的规模成正比，小的系统用大的架构是架构过度。大的系统没有良好的系统架构匹配，将对稳定性、工作效率、性能、bug率产生很大的损失。而架构在系统完成之初大多数是开不出来它的优势（不好的架构即使是发现了也可以打些补丁）。时间久了、业务变动了、扩展了、架构的优势就出来了。高内聚的模块不会轻易修改的。耦合低的模块将改动控制在一定的（可能是最小的）范围。
首先必须是一个好的解决方案架构师,1：将需求的业务逻弄清楚。2：按高内聚、耦合低的思想设计分割、组合模块。
其次必须是一个好的数据库架构师，好的数据关系在以后开发中受益无穷。
最后必须是一个好的系统架构师，开始代码分割、配置、选型、服务器针对方案。
当然如果你以前是f2e，那么你不做CTO就是埋没人才。

zhaopingzi

关于这个问题:
.双十一的秒杀战役中，一个购物网站要在一天处理完成超过1亿笔的交易，淘宝网采用什么技术架构来实现网站高负载？

我想说的是淘宝是否完成了1亿笔的交易？这个没证据。
淘宝网采用什么技术架构来实现网站高负载？，这个得问淘宝的工程师

jieforest

呵呵，架构之美。

CUTianrui007

1.“虚幻”的架构常常让人觉得它有很多玄妙之处，也许是因为它难以落在纸上，那架构到底是什么？它的主要表现形式是什么？有人说是图，您赞成吗？

架构的确很虚幻，让人难以琢磨，但物极必反，太虚幻了，那会就会落到实处。如果你仔细分析就会发现，一些简单的名词就可以折射出架构的思想。比如，回调函数，一般通过函数指针实现，它就体现了架构中的主动与被动两个方面，主动的是要调用这个函数，被动的是函数是由其它模块提供的。而主动和被动又将软件分成主体及边带，主体影响软件运行，边带是受软件运行的影响。诸如此类的名词，很多，很杂，关键就看你如何挖了。

在我看来，架构到底是什么？架构是软件表达的一个整体方式，它对软件提供了约束，它让软件以更加稳定高效的方式来运行。架构可以说是软件设计的集大成者，是软件设计的最上乘功夫，任何软件名词最终都统一的架构设计之中，所以基本的名词如算法设计，分层，分模块之类都是架构设计的具体体现者。

但架构设计真的很难，要理论深度，也要实战经验，还特别要靠悟性，期待哪天能达到架构师的水平。

机智的小学生

不错的话题，不错的活动。期待！

yunas

好活动，占好位置。
那架构到底是什么？架构是技术人力&技术成本得综合体。

yunas

发现架构之美，点赞。

action08

4.双十一的秒杀战役中，一个购物网站要在一天处理完成超过1亿笔的交易，淘宝网采用什么技术架构来实现网站高负载？



这个肯定是lvs，你看看tb有个技术总裁lvs的博士

pipihappy8888

回复 5# CUTianrui007 说的很不错！