大话微服务架构之微服务框架设计原则(二)

上篇本文和大家分享了微服务框架的技术选型，本篇作者将会和大家分享下微服务框架的一些基本设计思路和相关规范。

前面也讲到，和传统大而全的架构不同的是，微服务架构讲究的是一个小而美的架构，这个小可并不表示微服务架构是很随意的一个架构，这里也是要遵循一些基本的设计原则和规范的，麻雀虽小，五脏俱全！

这里说到的设计原则不是我们常规说的23种设计原则，这里讲的设计原则是根据我们前期如何契约这个微服务架构的。通常我们可以从以下几点考虑一下：

1、微服务框架含有日志追踪功能，这里的日志可以调用专门的日志微服务，不管是微服务自带的模块，还是调用其它服务实现，强调的是，每个微服务必须要记录错误日志和请求跟踪日子，便于微服务上线后，部署在成十上百的虚拟机或容器上面运行报错后，可以快速定位问题。

日志建议包含以下一些字段或属性，如请求Id,请求时间，请求地址，请求头信息，请求消息体（参数信息信息包含在里面），请求端Ip数组（包含代理ip，层层转发的ip，客户端原始Ip），处理请求的服务器端Ip（内网或外网Ip）,请求的服务地址、请求的响应头、请求的响应正文、环境变量信息（dev、sit、uat、beta、prod）、调试信息、错误信息等等。

其中，客户端请求Ip，如果中间用了nginx反向代理，nginx又没有配置相关模块的话，后端服务是获取不到真实客户ip地址的，可以添加http_realip_module模块来获取真实客户端IP地址，后续会专门出一个文章来讲解如何配置。

请求头中，也应记录下请求的服务接口地址对应的环境变量，比如是测试环境还是生产环境，因为有时预生产环境（有的人也称为沙箱环境）和正式生产环境都是部署在公有云上，光看ip一眼还是很难看出是哪套环境出了问题。

2、服务启动时自动向服务治理中心注册、服务挂掉时自动从服务治理中心注销。

每个微服务，不管是用什么语言开发的，都应该在自己上线后，向服务治理中心注册自己的信息，比如：服务唯一名称、服务地址、服务IP、服务对应的环境，这样才便于其它服务通过唯一名称找到你。服务注销是服务治理平台定时通过心跳检测每个微服务的检测检测api，当健康检查api返回no是，自动注销该微服务。

3、服务框架支持授权远程重启

由于微服务上线后，通常都是分布式部署，如果修改了一项配置，需要重启机器，每台每台机器的去登录手工重启无疑是一件很痛苦而又不靠谱的事，因为有时机器一多，难免忘记了个别机器忘记重启了。所有，每个微服务提供一个远程重启服务的rest api出来，通过一个公共的调度平台去调用，实现一键远程重启。

4、服务框架支持远程清理服务器端缓存

和远程重启一样，有时修改了业务库数据，但是缓存服务器缓存还没过期，读的还是旧数据，这时经常会用到远程清理服务器端缓存的场景，微服务本身如果提供了一个远程授权清理缓存的rest api的话，就可以远程一键清理，无需每台机器登录操作了。

5、服务支持Mock数据打桩（也可以交由微服务网关）

因为微服务开发是基于接口契约模式进行开发的，前后端都是基于接口契约进行业务开发，接口未开发完成前，前端需要调用接口的模拟数据，但是调用方法和调用真实方法是一模一样，只是在请求头参数中，设置x-api-mock=true,就可以返回自己事先设置好的数据。

当然，如果你们团队已经有微服务网关apigateway了，微服务框架本身就可以不同具备这项能力了。

6、服务之间尽量用restful api通信

除非业务非常复杂、需要异步RPC机制进行通信才能解决的，尽量用restful api进行通信，因为rest通信是语言无关性的，只要能支持http(s)协议就能相互调用，而RPC通信是强语言相关的，要为不同的语言提供SDK，这样违背了微服务本身的设计初衷，因为微服务提倡的是语言和平台无关性。

7、配置集中化管理

当微服务达到一定规模时，想京东的微服务部署在上万的Docker上面，如果配置存储在每个微服务自己的配置文件里，如果需要修改下某个配置，可想而知是多么困难，所以，微服务的配置要集中化管理，每个微服务在启动时，像配置中心一次性拉取本服务所有相关的配置，存储在缓存中，如Redis中，当配置中心的配置修改时，会以消息的形式通知到每个微服务，这次微服务会更新本地的缓存重新拉取新的配置。配置中心其实就是一个键值对，然后这个键值对和每个微服务关联一下就可以了，可是很简单的实现，也可以像SpringCloud一样，把配置文件直接已文本的形式存储在一个公共地方，大家都去这个公共的地方去读取。当然，有些实力很强的公司，都会把配置中心做得很复杂，比如淘宝的Diamond，360的QConf，百度的disconf，携程的Apollo分布式配置中心系统，这些都已开源，但普遍都比较复杂，而原理都大同小异，不过，追求完美的人可以逐个研究学习一下，里面的思想还是很有参考价值的。

下图是携程的Apollo分布式配置中心系统架构图：

UI界面还是挺美的哈。

百度的DisConf:

淘宝配置中心：

360QConf:

8、健康检查

微服务自身提供健康检查的rest api，用来判断服务是否在正常运行、标准可以由每个微服务自己根据业务特殊来自定义。

当然，这几点是每个微服务最基本的功能，只有每个微服务都遵守了共同的框架规范标准，才可以跨团队无缝高效协作开发，避免一个团队多套标准，乱糟糟的很影响开发效率。

用一张图归纳本文内容如下：