服务配置管理

• 服务部署的三种方式

• 微服务部署视频

• 服务配置管理有如下职责：

服务配置管理，功能类似于 m3的 Power.ConfigEdit.exe。不过是Web版的。

1. 告诉系统总共有多少微服务？ IP和端口分别是什么。
2. 哪个微服务是网关。 负责协调前后端交互的。
3. 总共有多少种数据库链接配置串。
4. 给每个微服务分配所需的连接串。
5. 配置微服务运行场景、 Token生成所需参数、 Redis的端口/密码、 可信任IP白名单。
   • 配置部署

Power.ConfigEdit.Web 网站 和M3里的 Power.ConfigEdit.exe 工具类似。
之所以不沿用exe类工具，主要是因为
.Net Core开发的微服务，可以在windows部署，也能在Linux下部署。 但 exe文件无法在linux下运行。
因此，我们提供了Web版的 网站配置工具。

     约定： 扩展名是 Web的压缩包，一般都含有网页。<br />                   扩展名是API的压缩包，一般不含网页，url返回信息都是Json数据。

a. 解压缩 Power.ConfigEdit.Web.zip （提取码:anat） 文件。
b. cmd -> 进入解压目录。
c. dotnet Power.ConfigEdit.Web.dll [端口号，不填端口则默认 19980]。

网站启动后，浏览器中访问： 127.0.0.1:19980 即可打开对应配置网站。

• 环境设置

微服务分为三种：

因为一个中大型环境，服务是比较多的。 我们担心对业务功能拆分太细，从M3的庞然大物这个极端，又走到了另一个极端。
因此提供了子服务的概念。 子服务一般用于哪些比较稳定的服务。
另外，子服务很容易切换成主服务。

微服务定义项， 也是对 [概述 三. 微服务体系扩展示意图] 最直接的描述。

这里强调下， 子服务和主服务之间并不是父子关系。 子服务只是为了方便部署，借用了主服务的IP和端口。 两者没有从属关系。
子服务也能很轻易的切换成主服务。
后续会对此做重点阐述。

微服务体系很类似现实世界的组织架构。 比如结合上图：
Power.Gateway 是网关服务。必须定义。 唯一。 有独立端口。 【首都】
Power.Login是子服务， 本例中我们把其挂在网关服务下。 【下辖区县1】
Power.Config 是子服务，本例中我们把其挂在网关服务下。 【下辖区县2】
Power.ConfigEdit.Web 是个独立网站， 唯一，有独立端口。 【天安门】

Power.ProjectsTrans 是数据迁移示例API。可以唯一，有独立端口。 也能降级为子服务，附属于某个主服务。 【省会】

由此可见，是否有独立端口，是分水岭。

在微服务环境下， 每个微服务都是一个独立的世界。
每个微服务也能拥有多个数据库连接串， 其中 ConnName 约定为默认串。

经常有这样的现象， 20个微服务，其实用到的数据库连接串可能只有3-5个。

那么我们就先定义这几个连接串。
然后把这些连接串，分配到相应的服务上即可。 尽量减少重复操作。

• 目前所支持的数据库种类

微服务平台对如下数据库提供支持。

• 微服务体系的视频讲解

• 微服务体系讲解补充