这次想写一个偏技术的话题，企业应用程序架构设计，鄙人对系统结构设计有一些特殊爱好，合理的体系结构，是软件开发中一切美好的事物即将发生的前提，反之，欠考虑的体系结构，会是噩梦。这里，我有一个小建议，作为读者的你，发现公司待遇不错，公司前景也美好，公司的活也不重，但是有一些A级人才总留不住，给承诺留不住，加工资也留不住，反正就是要走，这个时候，可以想想应该是某个方面错了，而且是无法挽回的错误，因为这些A级人才卓越的洞察力，发现了负责的系统在目前的时间，空间条件内，完全没有了可行性。其中，因为软件体系结构有问题而没法走下去的，肯定是一个重要原因之一。接着讲讲我的特殊爱好，其实也是我个人学习和实践总结的一些前辈们都经常传授的经验，观点。
世界上最美好的结构是层次结构。这是区区的第一个观点，如果系统没有分层，再多的理念在我看来也是一团糟糕。层次结构设计，是天然的，容易理解，设计经验也方便分享；让大型工程可以从容的分解，只需要对外发布提供服务的接口，同时使用低层次提供的服务即可，规范有序的使用原则，从而避免了复杂的调用关系。如果一个层次结构出现了多向循环调用，那他就不是层次结构，而是网状结构，有人说，网状结构不是更灵活，更有效率吗？的确如此，层次结构的好处是把复杂度控制在普通工程师都能控制的范围以内，天才能够掌握控制的结构，工程上极有可能不可行。如同tcp，ip协议族，这就是层次结构设计的代表作。
应用体系设计应该是松散耦合，体系中每个系统都应该具有独立运行能力，应该是可以轻松实现升级绑定与降级解耦。如同一只壁虎，平时拖着一只大尾巴，帮助自己储存能量，保持平衡，一旦遇到危险可以脱掉尾巴，还能够轻松逃跑，一点也不影响它的生活，至少是不会影响它的生存。如同操作系统，文件系统崩溃，操作系统还可以用，网络崩溃，也可以用……
应用系统架构应该是可监控，可调试的，而不是不知道它到底怎么样，可能会怎么样，它的行为是可以预测的，它的当前运行时是可以监控，应用系统作为一个体系运行，绝对不能通过猜测。因此，设计系统时，可监控，可调式，这些看起来多余的功能，多余的设计，是不能够偷懒，省略的，否则以后将会是一个很大的隐患。
接下来讲讲我们正在做的，我们设计的是一个在线的saas架构的企业服务系统。把一直以来的一些思考和外面学习的一些知识结合起来做一个易于实现 ，符合现阶段要求， 同时又有潜力发展的架构。
首先定义目标：
- 能够满足在线的注册即可使用。
- 数据安全与稳定服务
- 服务器集群的状态可监控
- 共享，独立的二级域名访问支持
- 每个组织都是独立的应用实例，互不影响。
- 每个应用实例能够快速关闭与备份
- 每个实例的使用，访问都是快速的，单个实例支持最高1000人的同时在线使用
- 实例个数扩展时，可以通过自动添加新的服务器满足扩展需求
- 实例降级时可以快速降级，缩减服务器与应用实例
- 应用实例自动升级
- 应用系统内部任意一个系统崩溃都不应该影响整体的系统可用性
- 系统之间没有强依赖，子系统可以随时剔除不影响应用服务的可用性
目标比较多，不过考虑的时候，我认为，有必要详细一点，做设计时，根据实际的情况可以分步实现。
整体的结构效果图如图：
逻辑结构分为：
前台系统
账号系统：用来管理用户的账号，登录，注册业务，帮助系统，活动推荐等。
应用实例集群：用户开启一个组织实例，获取完整的oa系统应用功能
后台系统
负载均衡中间件:各个应用实例调用批作业服务，缓存服务，监控服务的中间件，主要用来做负载均衡与路由转发
批作业实例集群：处理各种定时的或耗费系统资源较多的作业，比如邮件，短信，等
缓存集群：提供缓存服务，提高系统性能
备份作业系统：提供主动的备份机制，被动热备份机制，备份数据并保存到异地
监控系统：提供应用实例的日志，反馈处理服务，应用系统运行情况监控服务，服务器状况监控服务
自动部署系统：应用实例自动快速部署，自动升级服务，重装，回收服务，二级域名分配与回收服务
这里的系统每个单独设计都将会是一个挑战，有可能以后分开篇幅写出来分享。今天暂时写这么多，下一篇的主题我会想想是些技术相关的还是产品相关的，或者是市场相关的，有兴趣的朋友可以跟我沟通一下。
这段时间正在设计基于html5流程设计器，更新少点，见谅！
独步天下的创业历险记
我的文章首先会在微信公众号(acao1984)中推送，第二天将发布到我的几个博客频道，请关注我的同学，请关注我的微信公众号
曹志辉 “全栈工程师” 有观点的憋足程序猿， 夜光云科技创始人 正在做一个唯美的在线协同办公产品，我的公众号里将不定时分享 我个人的真实创业大冒险经历，关于产品，关于编程，关于职场，关于趋势，也可能包含其他话题，与各路朋友共勉。
