目录
架构、备忘和注意事项
理解IoT事业部网站产品的技术栈
前端 – Node.js
在Node.js诞生之前，Javascript主要用来做客户端的开发。
在Node.js诞生之后，Javascript可以用来做完整的后台开发。
这其中的原理很简单，Node.js的解析器(runtime)就相当于一个Chrome浏览器，并且对于OS拥有全部访问权限。
运行在浏览器上的Javascript受限于浏览器的权限，而运行在Node.js中的Javascript可以完全操作OS。所以，简单来说，就是现在你可以用Javascript来写跟Python、Java一样功能的APP啦。
IoT网站项目前端使用的框架是风头正热的Vue.js。
后端 – Spring Boot
Spring Boot是基于Java编程语言的微服务框架。
我们来看下它的组件逻辑图。
可以看到关键的组件有（括号内是实际使用的软件名）：
- Gateway – zuul
- Service Discovery – eureka
- Config Service – config server
拓扑
新架构（逻辑拓扑）
我不了解Spring框架，但是作为运维方，我们比较关心的有这些问题：
在Spring Boot自己的API Gateway之前，还有我们的Nginx，如果做HA架构，是否只需单纯地增加反向代理的后端节点？
答案是肯定的。注册到后端微服务框架自身的gateway服务中的业务服务有自己的名字，只要前端对应地访问相应的名字就行。
HA架构下，是否可以有多个Service Discovery、Config Service组件同时工作？
答案是肯定的。现在作为registry组件的方案一般有Eureka, Zookeeper, Consul。
他们都有各自的集群实现方式。
单节点情况下部署的情况
多节点情况下HA部署的情况
可以把上图的Nginx抽出来单独放（在生产环境下应该放在一个public子网），作为一个整体的网关入口，前端服务和后端服务（这些都放在private子网）都用这个网关做负载均衡。
e.g.
前端:
- server_name: registration.product-1.com ==> 192.168.100.1:3001, 192.168.100.2:3001
- server_name: registration.product-2.com ==> 192.168.100.1:3002, 192.168.100.2:3002
- …
后端gateway:
- server_name: aggregated-api-gateway.group.com ==> 192.168.100.1:3001, 192.168.100.2:3001
- …
前端访问后端:
- 访问product-1后端服务 ==> aggregated-api-gateway.group.com/gateway/product-1-user/
- 访问product-2后端服务 ==> aggregated-api-gateway.group.com/gateway/product-2-user/
- …
旧架构（物理拓扑）（待补充）
不补充了，乱七八糟……
参见部署product-3德国站时总结的笔记。
备忘和注意事项
IoT事业部的软件架构中，所谓新旧架构，指的是物理拓扑上的概念，不是逻辑拓扑上的概念。
i.e.
新架构：每个产品使用自己独立的基础设施。
旧架构：有些组件会部署在共用的基础设施上。
旧架构下的网站列表（待补充）
- Ahome.com
新架构下的网站列表（待补充）
- registration.B.com
- registration.C.com
旧的网站项目使用的各个组件的配置文件的仓库
内网环境共用的Service Discovery服务 – 10.20.0.152:8761
其Config Service服务 – 10.20.0.152:8763
http://gitlab.company.com.cn/system_operation/erp-config/tree/master
在这里看到注册进来的具体服务所使用的配置文件。我猜Spring Boot的业务逻辑是：
- Service Discovery启动。
- Config Service和Service Discovery建立会话。
- 其他服务和Service Discovery连接，“注册”到Service Discovery中。
- 可能是由Service Discovery告诉Config Service哪个服务注册进来了，你去拉取（git pull）这个服务的配置文件然后丢给他吧。
