微服务系统设计的思考

微服务 系统设计

系统设计

1. 模型计算中，所有的静态文件全部都是远程的，配置文件也是远程的(调试的时候配置文件可以在本地，线上的话配置文件就需要专门的管理。在指定配置文件的时候接受相对路径，绝对路径，url路径，甚至以后支持etcd和consul路径。local,dev,pro)。总而言之，需要一个专门管理文件的一个服务。
2. 如果文件发生变化，那么就需要重新加载一次，也就是说，以后构件的应用需要一个热加载机制。文件或者配置热加载，那么依赖配置的服务岂不是也要重新更新一次呢。
3. 而其他的文件，能放到数据库就放到数据库中去，能放到redis中就放到redis中，能放到消息队列就放到消息队列中。
4. 发邮件这个要作为一个服务存在(异步)，通过消息队列把信息抛出去
5. 日志信息等也抛到消息队列中(异步)，避免对应用造成性能的损耗
6. API系统尽量跟业务处理系统分开，因为API用的是web服务，而业务处理可能用不同的类库和包，其中通过通信的方式可能好点
7. 除了业务逻辑和配置中心之外的所有的东西都变服务。发邮件变成服务，日志处理变成服务，数据库操作也变成服务，通过接口调用的方式操作数据库(大部分进行的是查询操作的时候)。把单独的服务提取出来以便单独使用，以及对单独的服务代码进行优化。
8. 实时展现服务，用于终端的日志实时展示，用于查看其他的服务的监控信息。本来日志存储在数据库，但是你突然想看看当前的日志情况用于调试，而且，每个人想看到的内容也不一样，那么该怎么办呢？展现服务开启，日志服务把数据也给展现服务一份，如果想要过滤，那么就需要对route_key进行定制，需要用到topic模式模糊匹配了。实时展现服务相当于一个客户点，随时查看，随时停掉的。日志服务里面有一个fanout模式，用来接收实时展现服务的请求，不过，一般情况下，实时展现服务不存在，故而消息为空。当客户端连接成功的时候，展现服务fanout模式连接成功，然后再同时开启一个topic模式的本地服务端和客户端，route_key就是传递进去的route_key，同时每个实时展现的客户端随机生成一个独占的队列，用完就释放掉(topic模式)。
9. 日志服务后端连接实时展现服务，连接报警服务，连接日志分析服务等