作者回复：建议zuul网关之前部署LB(如硬件F5或者软件nginx)，这样LB可以对zuul集群做负载均衡。同时在LB层做https终结，这样zuul网关层只需处理http。

作者回复：谢谢支持！欢迎持续关注我后续的课程。

作者回复：划分边界的依据主要有两个： 一个是业务领域边界，比如电商的用户user，产品分类category，订单order，支付pay等等，常用方法论就是DDD(领域驱动开发)。 另外一个是以团队为边界，团队实际负责哪些业务模块，就以这个团队为边界划分微服务，比如互金领域的用户团队，借入团队，借出团队，资金团队等。业务规模不大的时候，可能一个团队负责所有模块，业务规模变大，则拆分更多团队和微服务。 实际企业中，一般业务领域+团队边界结合划分微服务。

作者回复：可以考虑只将在运行期会动态变更(还有不同环境有差异)的配置项放apollo配置中心，其余用本地静态配置即可，一个应用动态可配置项一般是有限的。所以项目可以经常重构一下，把不变的配置放在本地静态配置文件中，没必要全部放apollo。

作者回复：HystrixCommand实际是使用命令模式，你继承实现的Run方法是有返回值的，你把要执行的代码包在Run方法里头，正常执行Hystrix就会获得你的执行结果，异常时Hystrix会捕获，你可以在Run方法里头捕获异常和处理，但是这样Hystrix就没有办法再帮你做统一的异常处理了，也就失去了使用Hystrix的部分好处（异常监控熔断限流等）。如果确实业务需要，你可以自己根据需要处理一部分异常，其它的交给Hystrix去处理，这样还是可以获得Hystrix的熔断等好处。

作者回复：你好，consul + nginx + consul template可以实现nginx动态负载均衡，因为nginx是基于配置文件的，配置文件变更可以出发reload。zuul原生是不支持配置文件（除非定制），但是zuul + ribbon + consul应该也可以实现动态负载均衡，这个是基于内存方式的，具体参考spring cloud的官方文档：https://cloud.spring.io/spring-cloud-consul/spring-cloud-consul.html。

作者回复：运维领域的CMDB，主要是针对硬件物理资源，操作系统，常用软件等的配置信息管理，用途偏向资源配额治理和监控用途，也可以配合ansible/salt等配置管理工具使用，实现自动化安装部署。apollo主要针对的是应用和服务级别的配置，比如应用启动参数，连接字符串，甚至是一些业务配置等，它一般面向应用开发人员。总体上CMDB工作在物理运维层，apollo工作在应用和微服务层，两个层面的东西，虽然都管配置，但配置概念和范围不相同，并不直接相关。

作者回复：受信任服务一般是企业内部开发，性能不至太差，所以用信号量也OK。但是如果服务确实很慢，即使受信任，也要考虑线程池隔离，同时因为在企业内部，我们一般可以要求服务提供方改善性能。第三方的服务我们一般称为不受信，因为性能一般无法把控，可能很慢，我们一般也无法要求第三方改善性能。