设计一系统涉及方方面面。下面我们单从性能方面描述设计的考虑。
解决软件架构设计问题，我们遵循分而治之的方略。所以我们看到有横向的划分跟纵向的分层。这样我们才可能把问题各个击破。
在业务层面上，我们可以考虑把系统拆分成子系统。子系统相对独立并协调合作。自然我们可以考虑SOA。我这里并不强调SOA的概念，核心强调的是业务的分拆。如果子系统可以单独扩展，这样在遇到瓶颈是就可以对相应的子系统进行扩展。 这样子系统从数据库，持久层，业务层，服务提供层都相对独立开来。
再进一步我们考虑服务的部署。同样我们要考虑各部件的逻辑独立性。我们要清楚划分边界，Web服务器，应用服务器，数据库服务器，文件服务器，消息中间件.....我们要尽量保证各组件的界地。这样也是为了我们扩展的灵活。可以在相应服务出现瓶颈时单独扩展。
具体到各层应用的设计上，我们要考虑充分利用资源，同时考虑横向跟纵向的扩展。
在资源利用上，我们常面临I/O的瓶颈，从南桥（即系统I/O芯片（SI/O）：主要管理中低速外部设备；集成了中断控制器、DMA控制器。）到网络I/O。常常会成为我们性能的瓶颈。在系统设计时，我们不能寄希望于相应资源的升级，提升。从软件本身的角度出发，我们要考虑的是软件的机制。我们可以合理的设计缓存来减少I/O。缓存的可以在系统的各个层次。从数据库到客户端浏览器为了合理减少I/O，都有缓存的身影。引入一个方案能解决相应的问题，同时也要付出代价。缓存的引入势必带来数据一致性的问题。在设计时我们一定得归类各种数据，不变的，常变的，偶变的。还有我们还要考虑应用对数据一致性的要求。从多个角度我们综合分析是否 并如何引入缓存。
在说缓存的同时，我们要区分内存存储。缓存跟内存存储是有重要区别的。缓存并不保证被保存的数据一直存储。记得在Infoq上有一个文章专门指出我们不能用memcache来存储session。用他来存储会导致某些用户意外中断连接，这就是由于memcache的本质所决定的，它作为缓存并不保证对session的存储。而session实际上要的是存储。所以此文章建议用内存数据库来保存session.
说了I/O,当然我们还要考虑其他资源的有效利用。CPU, memory等等。多进程，线程，并行程序设计必然是我们要考虑的。多进程，线程能充分利用我们的CPU的计算能力。当然同时也会带来上下文切换的开销。所以要综合应用I/O的情况，来规划。如果是计算密集型的应用，太多的进程，线程调度反而适得其反。
在I/O密集型的时候，当然可以考虑引入异步的计算。其实当下很多的reactive的平台提供了很多异步的支持供我们取舍。
总之系统的无银弹，我们得从各个角度综合分析。