容器云，虚拟机
虚拟机和应用上云对Iaas厂商有了更高的要求，不仅在稳定性和可用性方面要有出色的表现，更加应该在易用性和便捷性方面展示出强大的功能，这方面必须能提供具有丰富功能和配置的UI界面，它有助于我们在Iaas的配置和运维层面减少工作量，优化人员配置，提高我们对Iaas的掌控能力，这是一个有和优的问题，另外对于厂商的选择和团队的选择，一定是要能及时响应的。
虚拟机和应用上云对Iaas厂商有了更高的要求，不仅在稳定性和可用性方面要有出色的表现，更加应该在易用性和便捷性方面展示出强大的功能，这方面必须能提供具有丰富功能和配置的UI界面，它有助于我们在Iaas的配置和运维层面减少工作量，优化人员配置，提高我们对Iaas的掌控能力，这是一个有和优的问题，另外对于厂商的选择和团队的选择，一定是要能及时响应的。
对于采用了容器的厂商，起码要在这几方面需要做好，集群的管理和调度，网络方案，服务编排，日志方案，存储方案，应用和服务的管理，容器的监控和告警，镜像仓库的管理，镜像的打包和构建，用户的权限，优秀的UI操作界面等等。
同样的对于容器，如果它是一个优秀的产品，那它还应该是这样的：
充分开放的和可扩展的接口。
可以和多个产品进行对应快速，如微服务产品。
丰富和体验方便的UI， 高度集成功能的UI，可见即可得。
充分的对接DevOps文化，丰富的CICD流程，镜像一键打包。
容器应用与非容器应用通信，跨集群通信。
优秀的监控体系
等等
这部分的能力是让整个技术中台有一个好的基础设施层支撑，能快速的进行应用的部署和交付，出问题时能迅速定位和恢复，降低MTTR, 并能充分的利用现有资源进行合理的分配，让技术和业务降低耦合，划分出业务实现者与技术支撑的BC，关注各自的领域，所以你需要一个非常靠谱和好用的底层支撑。
微服务框架(分布式服务框架) \u0026amp;\u0026amp; 微服务管理控制台
对于传统老应用而言，它可能是传统的单体应用，整个系统的功能都融合在一起。它们在迎接需求剧烈变化和传统开发迭代方面遇到了瓶颈，那么在转型时就会考虑服务化的架构，在做服务化架构时，我们就需要一个完整而健全的分布式服务化框架来帮助我们，诸如Pivotal的Spring Cloud框架。
但这里要提醒的是，如果你要打造一款真正的技术中台，我认为一个纯粹的Spring Cloud的框架是非常不够的，它只能说是一款开发框架，而不是一个真正的微服务产品，不能为业务开发提供充足的保障。
那么究竟什么是一款完整的微服务产品呢? 我起码认为它应该拥有这两个基本的能力：
第一，要拥有微服务框架技术能力。
第二，要拥有完整的服务治理能力，拥有应用全生命周期的管理能力。
第一部分是基础的微服务框架能力，这里面应当包括：服务注册，服务发现，负载均衡，熔断保护，服务路由，服务通信等。
第二部分是拥有完整的服务治理能力，这里面的内容比较多，一般会有： 服务的管理，可视化治理界面，服务构建发布，分布式事务，流量控制，监控告警，服务契约，链路跟踪，灰度发布，服务降级等等。
微服务产品这一节可以单独拿出来说，这里就不过多讨论，其实好的产品应该还要有其他部分考量，如对接各种其他技术组件和其他产品的能力。
业界的微服务产品有很多，这里列几款：
腾讯TSF产品，Tars产品。
阿里的Dubbo, EDAS系列。
华为的ServiceComb，ServiceStage系列。
蚂蚁金服SOFA系列。
Pivotal的Cloud Foundary。
微软的Service Fabric。
网易的轻舟微服务。
这部分的内容是我们技术中台的基座，它可以帮我们解决大部分在开发测试，网络通信，分布式等方面的难题，也是我们在构建微服务应用，技术组件，公共支撑等方面的基础，加上完整的微服务治理能力，能充分帮我们解决在微服务拆分后的管理和运维问题，所以这部分内容是相当重要的。 |
