D 的个人博客

向导程序一般功能为初始化配置参数，持久化用户选择的默认参数。这部分逻辑应该是与正常的配置逻辑有重叠的，用户界面上也可能有重叠。

 

但在设计时最好不要去考虑去复用，向导程序只是使用一次，而且会有些与正常功能有不同的细节。另外，向导程序独立逻辑实现也可能有助于性能。

 

比如，在博客程序中，初始化后需要发布一篇“Hello World”文章，初始化的发布文章的实现是可以复用正常发布功能的。但是这样会导致初始化的性能比较低，也会增加修改文章功能的复杂。

 

在一个非分布式服务的设计体系中，系统间的调用没有统一的服务接口配置（注册）中心，系统间的调用只能通过显示指定调用接口地址的方式。调用接口地址指的是 host，在开发环境中，数据库往往是所有开发共用一个，在联调系统接口的时候接口地址应该是从本地配置中加载的，否则的话开发环境很难做到配置独立，开发之间会互相影响。

 

比如，我在系统 A 上新开发了一个接口，和我联调的开发负责修改系统 B 来调用该接口，此时，如果系统 A 的调用地址是配置在数据库中，则联调的时候只能修改开发库的配置，这样就会影响到其他的开发（开发环境一般都公用一个开发数据库）；而如果系统 A 的调用地址是配置在配置文件中，则可以灵活地进行系统 B 的本地配置修改。

 

当然，调用接口地址使用域名并设置本地 hosts 也是一种可行的做法，但从整体服务内部接口调用这个角度出发，hosts 的方式是不提倡的，因为需要进行域名解析。

 

有的时候硬编码和做成配置文件其实在根本上是没有区别的，典型的例子就是依赖注入容器使用上，IoC 实现一般会同时提供注解、XML 配置、API 方式。

 

而如果是决定系统运行时的环境参数，是必须做成配置文件的。比如框架根据环境配置启用模块特性、切换运行模式。至少包含两套运行环境：开发环境和生产环境，这样方便部署切换。

 

另外，有的时候会有特殊需求要求运行期修改配置文件能够生效，如果有这样的动态配置需求，应该考虑使用数据库存取配置，而不是使用配置文件。

 

开发环境包括源代码版本分支、本地开发环境、应用服务器、数据库服务、依赖的远程服务。

 

实际情况下，最好时应该可以做到源代码版本分支独立、本地开发环境独立、应用服务器、依赖的远程服务独立，但数据库服务是基本不可能独立的，因为配置数据库系统与导数据是非常耗费时间的。

 

开发环境的搭建是比较乏味且易出错的工作，即使是搭建环境本身可以通过一些工具脚本进行，众多的应用服务器管理成本也是较高的。

 

消息服务是异步地整合系统间调用的一种方式，至少提供两种模式：发布/订阅（组播），点到点（单播）。

 

其最大的特点是异步处理，而发布方与接收方之间的松耦合只是消息系统的副产品，不应该认为松耦合是消息系统的特性。

 

消息系统的机制从调用角度看是一种隐式调用，既调用方与被调用方不直接在源码上依赖，而是将调用关系隐含在主题类型上。理论上所有应用场景实现上的调用都可以通过消息系统来实现，但实际不存在完全基于消息系统的架构，因为维护这样松耦合的架构成本更高。