danise

zipkin对应用有一定的侵入性，通过trace id 进行链路追踪。Skywalking通过埋探针，对应用侵入较小。

个人理解，微服务框架，比如spring cloud，dubbo，应用自己的注册和发现，更贴近于应用，他有自己的一套编程框架。而 容器云、service mesh 更贴近于基础设施，容器的承载体。

was默认是9060端口访问，映射宿主机相同的9060端口,应该就行了

上PaaS的应用最好满足12 factor，但是应用往往是有状态的，所以PaaS需要去对接外置存储。针对于docker也有很多的存储方案，针对于我们自身的情况，生产中我们将外置存储通过nas的方式挂载到集群的宿主机上，容器对外置存储的使

这个首先应用得支持多活部署。在两地分别部署PaaS平台，同一应用在两地的PaaS平台分别部署一遍，要保证外部依赖的一致和dns改造的完全。同时，镜像仓库唯一（它down了不影响应用）。应用的入口切换，依赖于PaaS平台外部的GSLB。

若考虑资源的充分利用，如研发测试环境，可采用在虚拟机上构建基于docker的PaaS平台；若应用对性能比较敏感，如大数据相关的应用对cpu敏感，可采用在物理机上构建基于docker的PaaS平台

PaaS平台的弹性伸缩，一定的条件下，基础资源（容器）进行横向的扩展或者释放，从而满足业务的需求。1、弹性伸缩需要满足一定的业务场景，比如纪念币的发行，需要提前人工干预扩展资源，之后再释放资源。2、自动的弹性伸缩，需要一定的

docker 组网方式很多，大多解决方案都采用overlay的组网方式，如果采用vxlan，性能损耗大概%10-%20，如果采用ipsec 性能损耗%40左右。如果采用扁平网络的方式（直接用IaaS的网路），性能几乎没什么损耗

商业版的PaaS如：bluemix，cloudfoundry，自行开发的一般都是基于docker的PaaS平台。有如下对比：架构对比：相同1、Docker框架和CF框架均通过容器运行计算任务，Docker框架的容器为Docker，CF框架的容器为garden差异2、Docker需要

F5 是硬负载，nginx和haproxy是软负载。PaaS平台的负载均衡需要感知PaaS平台的基础设施的变化，硬负载相对封闭，这里不做考虑。nginx功能较多，可以做web服务器也做lb，而haproxy专注于做lb，在转发性能上更优。 首先，PaaS平台