前言
在微服务中， 对于一个服务， 可能需要启动多个“服务副本”（这里的的副本指的是不同的应用程序， 但是服务内容相同）来提高服务的容灾性， 但是对于同时运行多个服务， 就会涉及到了一些问题。
下面是本次介绍的几个问题。
- 服务地址不固定
- 用户登陆状态的保持
- 日志记录服务名
- 集群及消费
服务地址不固定
对于多个服务来讲， 假如这个服务是被外部进行调用， 那么调用方一定要知道被调用方的位置， 而在生产中， 发布的服务可能会分散在不同的服务器上，这就使得ip地址并不固定了，那么有什么解决办法呢， 在微服务中， Gateway 网关起着很重要的角色， 同时还有注册中心， 通过服务注册和服务发现， 网关公国注册中心找到对应的服务，这时候在注册中心， 对于多个服务副本， 则可以进行负载均衡了。
用户登陆状态的保持
多个服务之间一般是用来负载均衡， 保证其中的一个服务宕掉， 服务依旧不受影响， 对于微服务， 设计中尽量是无状态的， 这样对于登陆的状态保持我们就无需关心了， 而对于有状态的服务比如通过session来保持状态，对于多个副本，则需要采取一定的措施，来保证用户在第一个”服务副本“上操作之后， 在第二个服务副本上的状态和在第一个操作后的一致。
对于登陆， 我们可以采用单点登陆（当然我们可以使用token的形式无状态)
对于session, 我们可以通过session集中存储，也可以通过负载均衡session sticky, 使得该用户后续的请求都是在同一台服务器上, 或者通过session replication, 使得session在每个副本上存在。
服务日志
在java服务中， 基本都是会日志记录， 记录可能会保存到本地文件， 也可能会被日志系统进行收集分析。 而对于多个服务“副本”， 需要在日志中体现出该条日志是由具体哪个服务产生的， 但是这些“服务副本”是一套代码，不可能发布一个服务时修改一下代码， 那么怎么能够在日志中做到?
环境：
1. Log4j2
2. springboot
3. java -jar 启动
1. 日志配置
我的思路是在服务启动时加入参数， 而log4j2日志中动态的读取到该参数，不同的服务启动参数不同， 这样日志中记录的服务名就不一样了。
如果对Log4j2不熟悉， 可以详见官网
下面是本次演示的logj4j2的示例：
<configuration>
<properties>
<!-- 文件输出格式 -->
<!--<property name="name">${sys:app-name}</property>-->
<property name="PATTERN">%d{yyyy-MM-dd HH:mm:ss.SSS} ${sys:app.name} |-%-5level [%thread] %c [%L] -| %msg%n</property>
<property name="LOG_HOME">/demo</property>
</properties>
<appenders>
<Console name="CONSOLE" target="system_out">
<PatternLayout pattern="${PATTERN}" />
</Console>
</appenders>
<loggers>
<asynclogger name="demo" level="debug" />
<root level="warn">
<appenderref ref="CONSOLE" />
</root>
</loggers>
<configuration>
其中最关键的是${sys:app.name},
在这里， 获取的是系统的app.name变量。
${sys:app.name}是利用Log4j2的Lookups, 我译为寻找， 即在不同配置、环境中找到对应的值。更多信息详见http://logging.apache.org/log4j/2.x/manual/lookups.html
2. 应用启动
springboot应用有多种启动的方式，
- java 命令启动应用, java命令中可以带有很多参数， 详见该文章https://www.cnblogs.com/z-sm/p/5674684.html。（本次采用这种方式）
其中几个我认为是比较重要的参数：
- -D<propertyName>=value 系统变量
通过System.getProperty(“propertyName”)得到value， 也就是上述对应的sys - -X 虚拟机参数
- -cp、-classpath
- -jar
通过
(java -Dapp.name=web1 -jar demo.jar &)
(java -Dapp.name=web2 -jar demo.jar &)
(java -Dapp.name=web3 -jar demo.jar &)
来启动应用
其中& 表示后台运行， （）表示进程不随终端关闭而退出
3. 集群模式
针对多个服务副本， 对消息的消费及任务的执行要保证在仅在一个服务内执行， 而不希望被多个”服务副本“执行。
在这里来看下面例子：
发布订阅
比如原本采用了redis的发布订阅功能， 如果该服务本来是订阅redis的channel，那么启动三个副本后， 就会订阅该channel, 见图下：
此时一个消息就被3个消费者消费了， 如果不采取一定的措施， 那么可能就会造成其他影响。
假如使用的是Kafka, 那么这些消费者在一个消费组里， kafka的一个消费组可以看成负载均衡， 一个topic的消息仅能被同一个消费组里的一个消费者消费， 这时候就不会出现重复消费的问题。
启动多个服务还有很多注意事项， 根据自己的业务场景， 进行适当的处理。
