saharabear
2013-04-04 22:17:20 +08:00
如果你想听更明白的，细节三天五天也说不完。
我做过五六年的企业开发，兼职做互联网，后来脱离企业开发全陪做了四五年互联网，最大的感受有这么几条：
1, 事务性
2, 并发量
3, 复杂度
4, 可用性
5, 集成度
6, 实施
别说我胡扯，虽然这几个词都很容易想起来所谓的“方案”里的东西，但是的确有区别。
打个比方，互联网产品对于业务本身来讲，复杂度要低一些的，比如文章发布，你很难想像文章发布的三五步审核流程能够与企业或者业务系统的公文审批系统进行比较，而这种审批系统，更复杂的地方是业务抽象，你说那是业务，不是技术？自然不是，要想把真正的业务抽象出来，这就是工作流了，这又是完全另一个领域。
再打个比方，互联网产品的高可用性自然重要，可是企业开发领域针对的可用性却不一定是7x24小时的意思，而是指各种容错性。
集成度，互联网产品可以用web service大量处理远程系统，但是企业开发中，如果需要异地高容错事务，那就需要消息系统，如果是带事务的消息系统，这又和互联网的需求不同的。
实施，一个业务系统能不能用起来，重要性相比较于开发本身，也一样重要。
冗余。互联网中为了性能，大量使用冗余，但业务系统中冗余本身就是一种极危险的操作，一定要专心设计。
权限，报表，工作流这几个是业务系统的必须组件。
别提淘宝支付宝这种互联网应用，这是金融应用的一部分，不只是互联网应用了，业务系统也有类似的大并发的网络处理，比如某公司全球有上百万人用他们的内部业务系统，在各地用vpn访问内部网络处理业务，当时也牵扯到大并发和低网速的问题，客户的需求很简单： 我全球的客户，如果能顺畅地打开yahoo，就应该能够顺畅地打开内部的ERP和其他系统。在这种需求下，业务系统也需要仔细设计http请求数，静态文件缓存，压缩等各种互联网细节。支付宝和刚才说的这种系统，是传统业务系统和互联网产品结合的领域。
楼主的面试很奇怪，你写的程序能不能经得起大并发，应该是程序场景决定的，如果他们没事就提什么千百万人访问，而不谈具体的技术实现思路和运行场景，那这事，我觉得不靠谱。