我的一位朋友正在为一个即将启动的编程项目而费脑筋：要在保证项目顺利完成的同时提高性能。他问我：“我该如何挑选技术呢？”这位朋友时断时续地编写过代码，但他还没有做过任何实质性的项目。他从未专注于任何特定的技术，他对这个项目不知如何下手。虽然他基于以前的经验倾向于部署到Linux，但这还不是最终决定。
在这儿，我将自己给他提的建议分享出来。我将不推荐任何具体的技术，而是告诉你，我在对技术和体系结构制定决策时的方法。
第1步：为应用程序作松耦合设计
敏捷方法已经变得非常流行，一些人认为，这意味着你不要尝试超越一两个星期的时间表。但这在为应用程序作松耦合设计准备时极具价值。您所需要做的只是使用一个具有流程图功能（例如Visio）的工具来提供一个高层次的逻辑概述。您不必陷入这样的细节：“验证这个字段至少包含五个字符”或数据布局。但你需要对应用程序各组成部分所担负的处理职责有一个总体思路。
这儿有图中应该包含的东西的一些例子：
- 任何重大的批处理任务。
- 数据存储（文件，数据库，“云”等）以及对之进行检索并提供给应用程序其它部分的组件。
- 重要处理出现的地方（在数据库中，在业务逻辑层，Web服务，客户端等）和它的作用。
第2步：确定资源的使用情况和特点
一旦逻辑概述图完成了，我们可以用它来确定资源的使用情况。你需要注意的资源是CPU、内存、硬盘空间和带宽。你要向外部Web服务传输大量数据或者与之相反？这就需要注意应用程序和服务之间的连接的带宽资源。也许你的数据库内部要做密集的运算 - 那就注意数据库的CPU使用情况，如此等等。
第3步：判断性能临界区域
一旦你明白了要使用哪里的资源，也就发现了潜在的性能瓶颈。这些地方会对你的技术选择有最大的影响。如果事实证明你存储在数据库中信息很少，你在数据库方面就有更多选择。也许你要在业务逻辑层执行的令CPU沉重的算法，这其中就表明你需要支持高速运算的语言和平台。下面是我以前做的图表，这会有助于您了解这会如何影响你的决策。
第4步：权衡需求规模
你可以从图表中学到的另一件事是你的应用程序的哪个地方需要权衡。例如，如果大部分处理需求是发生在应用程序的客户端，那么服务器架构可以宽松得多。
您也将能明白自己需要何种规模。大多数数据库有集群功能，所以如果你有选择，这通常更容易，更好地把需要权衡的事情（特别是如果它们需要在请求之间共享状态）推进到已经扩大规模的数据库，或考虑具有内置集群或缩放堆栈的更高级的技术。
结论
利用轻量级逻辑概图来启动应用程序的发展过程，你会在正确的途径上选择适合自身需求的最佳技术。也存在很多非技术因素（如您的预算，特别是技术经验等），但你需要从某个地方开始，这个决策过程将有助于你缩小选择范围，并提前看清问题所在。我很乐意你在下面的留言中，从而可以获得与这类问题相关的经验。
【编辑推荐】
