1.域名映射问题

部署一套业务程序，添加域名映射时需要注意。如果是内部之间互相访问识别，域名映射用内网ip即可。如果是给外部用户提供服务，域名映射则需要用外网IP。

2.启动或重启程序

启动程序时一定要注意用相应用户的权限启动，比如网关程序需要以root权限启动，并且自带守护进程。如果此时手动以hqop权限启动，会导致由两个网关程序，一个是root权限，一个是hqop权限。

3.程序异常时的排查思路

排错思路：先看日志文件，通过配置文件找到日志文件的目录，并修改日志文件的等级为debug，重启程序。

日志文件没有明显报错则去检查配置文件是否有问题。

4.gdb

gdb程序用于服务程序的调试。

先登陆服务器看报警程序是由什么程序调用

如果有服务调用了gdb，表示该服务进入了调试模式，即该服务不正常。

ps 看不到不正常程序的情况下，看下短线精灵依赖程序是否都正常在线

程序都正常，再看指标有没有异常。

指标也正常的情况下，表示此次报警可能影响不大，再去看日志排查报警原因。

/hqdata/monitor/monitor-hq-checktop/log/ ----- gdb日志目录

/var/log/messages ---- 系统日志目录

5.更改业务后端服务器

将10.20.3.168、10.20.1.166程序中的数据源10.20.3.200换成10.20.3.193

1.先看10.20.3.193是否支持quote类请求

vim /hxapp/hqserver/conf/httpd.xml

不支持的话需要手动添加支持

2.修改配置文件完毕后需要重启程序。/hxapp/hqserver/bin/hexinl2cs64 -d -smode=time

如何确定是该程序，看10.20.1.166机器的请求是什么

看日志得到请求的服务器端口和请求样例

然后到目标机器上看看监听该端口的程序

由此知道需要重启的程序为hexinl2cs64,重启该程序使配置生效。

然后先手动请求，看看请求是否能够到达目标主机并和原来配置的数据源请求到的数据对比，是否一致。

一致的话说明没有问题，可以修改配置中的数据源。

请求来自日志文件。

请求发现结果一致，没有问题。

curl "http://10.20.3.193:8080/quote" -d "method=quote&codelist=33()&datatype=415&datetime=0(0-0)&method=quote&rettype=json&"

然后就可以修改hxcalcext.ini配置文件中的数据源，并重启程序使配置生效。

6.服务隔离

什么是「服务隔离」呢？

顾名思义，它是指将系统按照一定的原则划分为若干个服务模块，各个模块之间相对独立，无强依赖。当有故障发生时，能将问题和影响隔离在某个模块内部，而不扩散风险，不波及其它模块，不影响整体的系统服务。

一、为什么要做服务隔离设计呢？

我们在做系统设计的时候，必须有一个清楚的认知是：任何软件系统，故障是不可避免的，并且大多数还是不可预测的，因此，我们只能在系统的设计之初就充分的考虑好应对措施，如何在故障发生时，去尽最大可能的止损和减少故障范围。

没有人敢说他的系统是百分百可用，我们能做的就是，使用一切方法去减少故障的影响面，尽可能的去提高系统的整体可用率。

而把系统分离成子服务，将子服务进行一定程度隔离的做法，能保证在有不可预测的故障发生时，缩小故障范围的最佳手段。

二、服务隔离应该怎么做？

那在实际项目中，一般通过什么方法去做服务隔离呢？主要有以下两种：

• 按服务/功能做隔离

• 按用户分类隔离

比如上图里面，微博项目可以把 Feed信息流、用户系统、评论系统 都分拆为独立业务模块，这些模块无论是对外的接口应用、还是到数据库、到底层硬件资源都是完全隔离的。其中任何一个模块的故障，理论上都不会影响到其它模块。

再举个例子，如果我们要设计个电商平台，可以将其中的 用户系统、订单系统、支付系统、仓储系统 都分别进行独立隔离，这样做就是从服务层面实现了故障的隔离效果。

那按照服务隔离有没有弊端呢？有，肯定有。

1. 当我们某个功能操作需要关联多个服务模块或者同时查询所个模块数据的时候，代码写起来就会相对麻烦一些了，其中涉及到多模块调用的性能问题、数据一致性问题、事物问题等。

1. 不同服务模块之间的交互也会比较复杂一些，因为要做服务隔离，避免服务强依赖，所以模块之间的交互调用最好是走异步模式，需要通过异步线程或消息中间件来传递实现。

1. 在进行运营大数据分析的时候，由于数据是散落在不同服务模块的，因此需要做额外的汇聚操作，还得有唯一字段保证数据在不同模块产生的先后顺序。

简单一句话解释就是：我们先部署多套一模一样的业务服务，然后将用户根据一定的特征去做分类，让不同分类的用户去访问不同的业务实例，达到分流和隔离的效果。

怎么给用户分类？

可以用按照用户是否VIP、用户等级、用户IP等等，方法很多，要结合自己实际业务的特性来做。

其实这也是一种「多租户架构」，在SaaS服务中用得比较多。

多租户模式有三种形式：

1. 完全的隔离，即服务和数据都是完全独立的。

1. 公共服务、独立数据源，即多个租户是用的同一台服务程序，但是底层的数据源是独立的。

1. 公用服务、公用数据源，即多个租户的服务程序与数据库源都是共享的，不同数据可能会做分区分表来独立。

上述三种方式，从下到上，独立性和安全性越来越高，资源利用率越来越低，根据业务特性去选择，一般选择折中方案。

另外，功能隔离和用户隔离 两种方式并非互斥的，是可以结合在一起使用的。

三、服务隔离的注意事项

我们在做服务隔离的时候，还是有一些原则和事项需要注意的：

1. 不可越界：能在隔离模块内完成的逻辑，就尽量不要跨模块调用，减少依赖。

1. 不可共享：数据和资源能独享的就尽量不要共享，不然很容易造成隔离失效。

1. 考虑效率：设计隔离模块的时候，要根据业务情况而定，充分的考虑到未来的拓补结构，减少调用效率的损失。

1. 考虑颗粒度：隔离模块设计的大小问题，过大和过小都不合适，需充分考虑。

1. 服务的全面监控：既然服务或用户进行隔离了，那么系统的复杂度肯定是比之前要高了，那么针对多服务的全链路监控是必不可少的。

服务隔离的设计模式能降低依赖服务对整个系统的影响，保护有限的资源不被耗尽，提高了整个系统的可用性。本文参考了很多其它资料，属于抛砖引玉，希望大家能一起交流，提出更好的架构设计思路。