如何应对系统的快速扩张

　　如何应对系统的快速扩张？我相信这是很多类似的公司所必须面对的问题，或许每个公司有自己的处理方式，不过下面我将要说说我的一些观点：

　　1，拆分系统：当公司系统做得很大时，业务功能耦合得越紧那么发布出错的风险就越高，此时通常会选择尽可能的拆分主要包括：面向服务拆分、多层架构拆分、网站UI按业务块拆分，数据库拆分等

　　2，尽量不要让多个服务间保持联系：现在很多公司的系统可能大多业务都是面向服务了如WCF，也就是说可能已经将原有在一个WEB系统里的业务分拆到一些WCF服务里了，但可能由于在设计服务时没有考虑周全导致了众多服务程序，再加之每个服务的业务领域规划不合理导致一个业务功能可能涉及到网站-服务-服务-服务等这种跨多个服务的调用方式，我们应该尽量避免这种情况发生，因为这种方式本身从性能效率上来说就比较低而且还加深开发人员集成测试的难度，发布版本时出错的风险也会增加。

　　3，外围程序如何开发如何管理：一个公司的快速发展除了核心系统的不断更新壮大外肯定还会有一些单独的小程序，这些程序通常用来处理一些单一的业务，但是这些小程序的更新频率又不是很高，有时甚至几个月才更新一次。由于很小程序有一些业务代码可能在核心系统里已有可以就直接拿来用了，但是一旦小程序需要更新时很可能会再次引用核心业务的代码如DLL，然尔如果核心到业务系统的DLL设计不够优秀就会出现一些问题，如果配置文件的依赖。为此我觉得为了让一些外围程序有更好的维护需要注意几点：1，能预见有共用功能的业务模块尽量设计成共用的DLL； 2，共用DLL最要不要依赖配置文件，如果必须有那么请您避免静态初始化，3，小程序要有一个统一的监控程序管理起来。

　　4，日志管理及监控系统：通常日志是最好保留程序现场的证据，做好日志记录及监控对整个公司系统的快速响应、解决问题有至关的重要性。为此公司通常会制定一套日志规范，包括如何记录日志，日志格式等，有了日志后还需要提供一个日志查询系统以便于查询。最后还需要一个监控系统，监控的目的在于主动去分析日志主动用出响应，越直观的方式显现出结果越好，工作人员通日志监控能很快的发现并通知相关人员即时解决。

　　5，数据库系统：基于这一块我本身直接参与不多，但我知道一个优秀的DBA对于公司数据库管理来说必不可少。好的公司通常不只一种数据库，或许有mssql,mysql, oracle或其中之二，有些还有一些nosql。为什么会这样？主要是公司业务众多的情况下从成本用途方面出发确实应该选择更合适的存储系统，但如果更好的利用就需一个优良的数据库架构，只能有了优良的数据库架构基础，然后才能开发出更优良的上层应用程序。

　　目前就想到这么多，欢迎分享！