Bestwiz FX产品化路上的建议


2014年从msn space存档中重新恢复出来!

因为一直忙于BATCH TEAM的日常管理和开发任务,可能对整体系统把握上不是十分的全面,故此,以下观点可能存在些许偏颇,如要施行,希望仅以谨慎之态度而为之。

系统架构上的调整

程序架构上的调整

核心模块和功能不应该过于耦合与底层资源以及其他功能实现的管理,进而导致各个模块与核心模块的耦合性过高,作为核心模块以及提供的功能,应该提供足够的灵活性以保证依赖于之的各个模块和功能能够容易的集成,而不应该强求各个模块紧密耦合于核心模块和功能所依附的底层资源和功能。

应该在现有程序架构基础上,抽取并规范各个模块交互和功能的接口,以保证各个模块之间的规范化交互和整体上的一致性,对于任何机构和产品来说,一致性是至关重要的。

整体架构上的调整

  • 逐步抽取并规范主要模块和功能,使之可以独立于各外层模块,而不应该与各外层模块绑定太紧,实际上,可能原来的设计理念就是在核心模块和功能之上包括不同的facade以保证整个系统的可扩展性,但起码现在没有得到严格的贯彻和执行。
  • 引入可插拔的模块设计,新的功能模块可以以热部署的方式发布,尽量保证服务不重启的情况下进行模块发布和维护工作。这样的好处就是,即使某个模块新的版本出现问题,也可以通过rollback到上一个版本来避免长时间的服务中断。当然,这个理念实现和执行起来可能不是像说的那么容易,毕竟,这个需要从整体系统进行考虑,单一模块实现模块的版本化控制没有太大意义,虽然也会带来一定的好处。

应该加入统一的管理接口

现在整个系统没有统一的管理接口,只有被动的监控机能,而且监控方式繁多。对于一个系统来说,监控是一方面,可以对系统状态进行调整则是另一方面。

监控可以有很多手段,但如果针对同一个系统,却拥有方式繁多的监控手段,对于系统维护和运营不能不说是一个很大的负担,统一化监控手段应该是产品化的路上的一个关注点。

一个成熟的产品,不应该只靠被动的监控来保证系统的正常运行,更应该考虑主动的对系统状态进行调整。这实际上是现在的FX产品中最缺少的一环。如果某个系统参数导致系统性能下降,不应该是靠重启服务来调整,在运行时调整并保证服务的正常执行才是比较令人满意的解决方式。

待续…

BTW. 今天晚上酒喝大了,头疼的情况下写下的文字,恐怕只是部分呓语,呵呵,看官最好加入自己的判断。可能以上所有的东西都是Nonsense。


>>>>>> 更多阅读 <<<<<<


「福强私学」来一个?

「福强私学」, 一部沉淀了个人成长、技术与架构、组织与管理以及商业上的方法与心法的百科全书。


开天窗,拉认知,订阅「福报」,即刻拥有自己的全模态人工智能。

订阅「福报」