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