核心实现-多租户资源隔离
云的特点是资源池化，甚至为每个用户开辟他自己独有的应用资源空间，而与其他应用隔离起来。我们称之为“多租户机制”,比如k8s的namespace就是实现了这种隔离机制。
如何实现哪？
1）对于Iaas，VM是资源隔离的非常好的手段，但是比较重。
2）LXC实现了OS级别的资源隔离，并演化成类似Docker这种隔离手段。但是依然是本地隔离手段。
3）需要结合1-2的本地级隔离手段，在Paas上层的资源分配机制上进行处理，资源分配时将各个资源汇聚成一个隔离的组并挂接或者注册到一个App的“名下”，这些都需要配置和元数据管理的支持。 以后再分配资源时，其他App将不会获得当前App的资源，并且当前资源如果崩溃，也不会影响到其他应用。
4）网络也可以进行隔离，比如Vxlan，或者划分专有网络：计算网络、存储网络、管理网络等等
核心实现-全链路跟踪和分析系统
核心实现-链路优化
将监控集群状态的心跳与集群命令下发合并，优化通信线路的负载。
核心实现-部署自动化-系统层面
核心实现-部署自动化-应用层面
1.部署时涉及编排的问题，也就是服务应该以何种状态部署哪一个容器或者节点上，以及与其他节点的关系策略：相亲性和反相亲性。
2.部署时还涉及版本管理、配置管理、持续发布和持续集成的问题，用于更好的走完生产的最后一公里。
但是在开发应用期间是建议频繁地在测试环境部署验证的，可以尽快发现问题并演练部署策略和程序
核心实现-不可忽视的本地治理
1.整体由部分组成，部分的效能最大化就是整体效能的最大化的重要因素之一，整体效能还取决于各个组件的整合和协作方式的设计以及实现。首先实现本地合理的治理，是必须实现的事情。
2.RPC的效能、服务器线程以及IO的处理方式、埋点的透明化、本地监控、本地缓存、本地调用调度（节点管理器），本地升级策略等等都是要关注的点。
3.生命周期管理：节点管理器必须实现对服务实例的生命周期管理，并与集群管理器紧密结合,在节点服务失败或者崩溃时可以试图重新恢复和拉起服务进程或者通知上层集群管理器重新调度。
核心实现-监控闭环
移植遗留系
1.以上的内容，说明了Paas的三个核心内容：开发设施自动化、运维自动化和运行时环境自动化。
2.但是这样的情况直接导致了遗留系统迁移的困难，因为老时代的系统往往很“重”，一开始就被锁定在厚重的铠甲中，另外一个更加让人为难的就是释放铠甲必须修改应用代码，这就涉及业务、功能重构！ 这也是很多企业实施Paas很艰难的原因！
3.具体的一些情况：
A:系统服务之间使用独立密码库授权通信，难以使得自动化手段开通策略，实现自动扩容和伸缩。
B:老应用代码依赖于应用服务器的Api，比如很老的系统使用EJB架构。使得适应新的Paas变得非常困难！
C:上Paas的动因也在于老系统面临的环境从内部走向外部了，但是之前架构师设计系统时是按由里往外的思路进行的，比如重点放在交易模块上（因为此时线下活动占主流），因为业务的发展，对系统的要求越来越高，要适应互联网环境的要求，比如互联网上查询的量要远远大于交易的量，正好和原来的思路相反，是从外向里的，这造成应用架构的极大不同，那么就要求调整到分而治之的架构，那么必然要求要进行调整和重构。
D:….......
那么就没有很好的办法尽量减少这些麻烦吗？因为麻烦意味着风险和成本
移植遗留系统-解决思路
1.总的方向就是向自动化、自省化、弹性化等努力。
2.我们可以通过回答以下的问题来决定如何调整您的系统：
A:本地应用不要依赖于本地的存储来持久化数据（可以临时性的，但是给系统带来风险），日志变成流汇聚到分布式日志系统中，如果非要使用存储，请使用类似HDFS来保存，您的系统是否依赖于本地存储哪？
B:如果应用上传文件，那么这些文件应该如何存储？请参考问题一。
C:集群中多实例的配置文件是否完全与底层OS解耦，配置文件是否不依赖于主机名和Ip？（可以采用环境变量来解决）
D:应用是否存在需要很长时间处理的任务类型？（尽量异步化的方式解决）
E:集群中实例是否采用了独立安全授权的方式组建？（需要拆除）
F:集群中是否使用了硬件负载均衡设备？（需要撤除）
G:需要把服务无状态化，您的App到底有多少部分需要依赖状态？
H：您如果拆分业务系统，是按业务视角还是用户视角？（建议采用业务视角，因为热点根本无法预测）
I：业务拆分的原则是：识别基础核心业务能力、业务核心能力、上层业务能力等
应用架构:CQRS
微服务是什么？
在分布式、云等基础设施支持下，从SOA演变而来的、具备明确的事务上下边界的、松散耦合的、可以并行开发、简单开发、简单或自动运维的、相互协作形成有机整体并为外部应用提供自省治理的、不间断的、高性能的服务系统。
前面提到互联网的分而治之的策略，大规模的分布式服务化系统在稳健的服务治理、弹性拓展、容灾以及开发周期能力支持下变得可管理、开跟踪、高性能、高生命力。服务化的基础是基础设施的稳定力！只要有一个坚如磐石的基础设施，服务化就是非常可行的决策！
套娃-软件架构之殇
1.在介绍核心实现的部分中，提到配置必须先行的道理，就是要保证内环境和外环境的一致性。
2.Docker虽然可以保证内部小环境的一致性，诸如CoreOS之类可以保证OS级别的版本一致性，但是Paas由于是分布式系统，它的各个组成组件也需要一致性保证，否则很难保证服务质量和延续性。
可以采用冗余服务+滚动式升级的办法解决这个难题。
不要把焦点仅仅放在Docker上！
最近一年来，看到Docker几乎弥漫在各种系统中了，但是Docker解决了App内部环境一致性、解决了传统Paas弹性拓展和容灾时效的问题\基准镜像分发等等，但是从架构上看过去，它本身并不能解决App生产的其他大部分问题，所以当您仅仅关注Docker的话，那就失去了Paas的能力，K8s、Swarm、Mesos等解决了一部分自动化问题，但是还不完整，只是算是Mini Paas。
微服务化与Docker的关系
微服务是活在Tomcat或者Docker里面并没有本质区别，之所以业界喜欢采用Docker作为微服务的设计期和运行时基础，是因为它有着诸多好的有点，比如环境一致性可以简化配置管理、简化Paas生命周期管理的难度等等，但是本质来讲，微服务和Docker并无强关系，只是Docker的诸多方便之处，更加适合而已，所以采用Docker的系统未必是微服务，微服务构建的系统也未必是Docker构成。
Paas的未来
经济的发展、业务的发展所导致工作量的增加将促进PaaS得到采用。
IaaS提供商将往堆栈的上层移动，涵盖PaaS IT，大量的中间件被云化。
公共PaaS将赢得中小企业市场，因为它提供了开箱即用的基础设施。
公共服务将把大企业市场让给私有PaaS。
开源PaaS平台将蓬勃发展，形成助推的作用。
开源PaaS平台将通过流行的Linux发行版来提供，进一步简化Paas的管理复杂度。
专有的PaaS将开始如同开源产品，也体现出业界标准化的意愿。
PaaS兼容性 更像是PaaS冲突性，由于各个厂家为了在竞争中取胜，也会更多的在自己的特殊性上下功夫，造成标准的不统一的局面，但是在市场的驱动力下，标准迟早会统一起来。
Paas变成一种生产互联网产品的工厂，逐渐成为标配，并融合在日常的基础设施中。
