首席架构师汪洋坐镇，欢迎大伙提问啊：软件架构连载讨论之二：架构设计解惑！

yanyangtian4502

回复  yanyangtian4502


    我认为,企业分大小,项目不分大小.
    企业级别的项目,应该是用于生产环 ...
chenyx 发表于 2011-11-03 18:43

    这位朋友说的很对，其实”企业级项目“与项目的大小，是否是为公司  政府 组织 无关的！我稍后给出一些“企业及项目”的缘由和一些特性

sytpb

回复 6# yanyangtian4502


    没有。

fire_cpp

1、关于“企业级”。我不太喜欢这个提法，“企业级”这个词在大多数时候是增加你项目谈判筹码的词汇，而非提高软件质量的词汇。操作系统内核（我更倾向于指开源操作系统）开发者从来不说自己的软件是“企业级”，但其伸缩性、稳定性、性能却是一流的。但人却是容易受词语影响的动物：同样一件事情，用不同的词语表达，听者（乃至表达者）都会有不同的、情绪上的微妙区别。

“企业级”有不同的提法，很多时候这个词为交流者之间提供了一个共同的语境。

2、实践上，我感到设计实在是非常重要。新人很容易陷入写代码的“激情”当中，虽然这种激情不可或缺，也可能是每一个人必经的阶段。不过话说回来，没做过大项目的人、没纠结过的人是无法体会设计的重要性的。而我认为设计的核心能力在于抽象——业务抽象与系统抽象的结合。

拿一个项目来说，如果因为系统面对的业务比较复杂、不确定性比较高（我们的工作不是经常面对这种情况吗？），一旦设计缺乏弹性，那么业务的变化很有可能让写代码的人抓狂甚至不知从何做起。如果设计时抽象得恰到好处，业务发生变化时你会发现“哦，原来这几个类可以这样用啊！还好当时是这样设计的！”。

至于基础设施这一块，新人容易陷入另一个误区：过度陷入优化，号称要榨干软硬件每一滴血。其实，大规模的应用，可扩展性更重要，这样考虑一是基于成本、二是基于可靠性。成本方面，如果能通过增加内存或者几台服务器提高服务能力，何必花几个人的半年时间来开发一个新的算法呢？可靠性方面，如果你把服务器的性能全榨干了，利用率达到了95%甚至100%，那么一旦有突发事件出现你的系统将很危险。当然不是说算法与优化不重要，而是说这应该与成本及其它实际方面取得平衡。我想这也是企业级系统与科研性质系统的区别吧。所以在实际中我们很少争论是linux还是freebsd在高负载下谁更优秀——如果经常处于高负载（比如70%以上）那么从“企业级”这个词出发，你的系统可能应该扩展了。

3、架构？
不在行，不是架构师啊。



大清早的，不知道说些什么……有感而发，不着边际，随便聊聊而已。

工作中我比较郁闷的是不知道除了经验之外有什么好的办法（或理论）能确保设计不过度、同时又有充分的弹性？
另外，架构师们，CFO会找你们的茬吗？

yanyangtian4502

回复 13# fire_cpp


    说出来很多的实情，有机会大家交流下？！

fire_cpp

回复  fire_cpp


    说出来很多的实情，有机会大家交流下？！
yanyangtian4502 发表于 2011-11-07 10:28

    我所知不多，水平不够，有机会能与您交流肯定获益不浅。

yanyangtian4502

在很多的时候，每次和一些技术人员讨论有关架构的话题，特别是在实现方面，很多的朋友，也包括很多的网上的文章  总是将架构与模式等同起来：每谈架构，比谈模式。

其实架构设计绝不是等于模式（设计模式，架构模式，集成模式等），架构设计 不仅仅涉及到技术的成分，并且还涉及到很多的“软”技能，并且 这些技能的重要  甚至比技术更加重要

yanyangtian4502

如果 硬是要把架构设计 与模式 放在一起 ，那么 可以这样说：模式 仅仅只是架构设计中的所涉及到的技术的一部分，甚至只是很小的一部分，如果把整个架构设计的技术体系比喻为一个大楼，那么模式 仅仅只是其中的几块砖而已

litdong

架构模式难道不是应用到架构上吗？

设计模式我的理解就像战场上连排的战术技巧，比如如何利用手中兵器有效组织步兵火力，班组如何保持战术队形，各个班组间如何通讯等等，属于战术范畴，一个人不行还不至于影响他人。

架构模式那就是团师高级别的，战役目的是啥，如何分配兵力，如何预留预备队，各团如何组织进攻，各团如何区分战斗范围，各团如何做相得益彰的协同，炮火如何支援，如何运用特种兵器打击敌人等等，属于战役范畴了，水平高低取决于指挥员和参谋的水准，这几个人不行，那基本就完了。

不同的项目也是不同的作战形式，比如平原作战，山地作战，丛林作战，平原作战就要发挥装甲部队快速突击的能力，山地就是要强调轻装部队等等。这些不同的地形引发的装备（技术）的改变，班组单兵作战方式（设计模式）的改变，甚至组织形式的（构件）改变这就叫架构的改变。

crazyhadoop

要做好架构设计我觉得要有2点要做的非常优秀：
1）系统分解和设计
  设计者需要将系统整体分解为更小的子系统和组件，从而形成不同的逻辑层或服务。关键一点是要松耦合的确定各层的接口，层与层相互之间的关系，个人感觉这里需要熟练掌握设计模式，但并不拘泥于设计模式，以便系统后期横向和纵向都能无缝，顺利的扩容。

2）技术选择
例如最近NoSQL数据库非常火热，很多项目都用Mongodb来存储数据，并搭配Hadoop来处理数据，为什么要选择Mongodb，使用这个数据库，技术人员能否稳妥的把握住Mongodb的行为，最近有一篇非常火的文章，盘点Mongdb的8宗罪。http://hb.qq.com/a/20111111/000205.htm  这对系统的未来走向很重要

最后就是要有系统设计文档，最起码要给后来的维护者一个大致的概念，每个系统的设计功能是什么？有什么要注意的地方，需要做哪些改进，我看很多公司都没有这样的东西，哪怕在代码里能说上也行啊

crazyhadoop

回复 1# 无风之谷


    其实企业级这个概念我觉得已经过时了，现在很多服务都是互联网级别的概念，就算不是整个互联网，也是面对着一个特定的人群，服务范围已经延伸了