轻量应用服务器和云服务器有什么区别
一、使用对象的区别：轻量应用服务器主要针对单机应用，而云服务器则无此类限制，适用于各种应用场景。
二、可扩展性的差异：轻量应用服务器的配置选择有限，升级配置的灵活性较低。
相比之下，云服务器提供多种配置选项，高达数十种类型和上百种配置，支持按需升级。
此外，云服务器还能与其他应用如RDS、OSS无缝集成。
三、网络能力的不同：轻量应用服务器由于其面向单机的特性，通常不需要考虑网络扩展问题。
而云服务器，特别是在专有网络VPC环境下，用户可以自行定义网络结构，实现与线下IDC或其他云产品的网络互联和互通。
如何用OpenStack和K8s快速搭建一个容器和虚拟机组合服务的云平台
搭建OpenStack云平台时，首先明确，无需对服务器进行虚拟化操作，除非计划在虚拟机上搭建OpenStack。
对于计算节点和存储节点，建议使用裸机以确保性能，降低复杂度。
至于控制服务，如API服务、scheduler服务等，如果无需高性能要求，考虑使用虚拟机是合理的选择。
构建容器和虚拟机组合服务的云平台，OpenStack和Kubernetes（K8s）的集成是关键。
OpenStack主要负责资源管理、调度以及基础设施即服务（IaaS）功能，为容器和虚拟机提供运行环境。
K8s则专长于容器管理，提供自动部署、扩展和维护应用容器化的解决方案。
集成步骤中，首先需在OpenStack环境中配置K8s集群。
此过程通常包括创建K8s节点、部署K8s Master节点、安装K8s组件等。
在OpenStack控制面板中，配置Neutron网络服务与K8s网络插件对接，实现网络通信的无缝集成。
其次，通过OpenStack Cinder服务或Swift对象存储服务为K8s提供持久化存储。
Cinder允许为K8s中的容器提供弹性块存储，而Swift则适合存储大规模非结构化数据。
实现OpenStack和K8s的深度集成后，用户即可利用两者的互补优势，构建一个高效、灵活的混合云平台。
通过OpenStack，可以轻松实现资源的动态分配和管理，而K8s则能提供强大的容器编排能力，满足现代应用的高可用性和可扩展性需求。
总体而言，通过合理的架构设计与集成策略，OpenStack和K8s的结合能够提供一个强大、可定制的云平台，满足从基础计算资源到应用容器管理的广泛需求，实现高性能、高可用的云计算服务。
阿里微服务框架dubbo(阿里的微服务框架)
Dubbo分布式服务框架介绍
随着业务的发展、用户量的增长、系统并发访问需求越来越大，系统数量增多，调用依赖关系也变得复杂，为了确保系统高可用、高并发的要求，系统的架构也从单体时代慢慢迁移至服务SOA时代，根据不同服务对系统资源的要求不同，我们可以更合理的配置系统资源，使系统资源利用率最大化。
而Dubbo则是SOA服务化治理方案的一个核心框架。
Dubbo作为阿里巴巴内部的SOA服务化治理方案的核心框架，在2012年时已经每天为2000+个服务提供3,000,000,000+次访问量支持，并被广泛应用于阿里巴巴集团的各成员站点。
Dubbo自2011年开源后，已被许多非阿里系公司使用，其中既有当当网、网易考拉等互联网公司，也有中国人寿、青岛海尔等传统企业。
Dubbo是一个高性能服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案，使得应用可通过高性能RPC实现服务的输出和输入功能，和Spring框架可以无缝集成。
作为一个分布式服务框架，以及SOA治理方案，Dubbo其功能主要包括：
Dubbo最大的特点是按照分层架构思维构建应用服务，使用这种方式可以使各个层之间解耦合（或者最大限度地松耦合）。
从服务模型的角度来看，Dubbo采用的是一种非常简单的模型，要么是提供方提供服务，要么是消费方消费服务，所以基于这一点可以抽象出服务提供方（Provider）和服务消费方（Consumer）两个角色。
Dubbo包含远程通讯、服务集群和服务发现与注册三个核心部分。
提供透明化的远程方法调用，实现像调用本地方法一样调用远程方法，只需简单配置，没有任何API侵入。
同时具备软负载均衡及容错机制，可在内网替代F5等硬件负载均衡器，降低成本，减少单点。
可以实现服务自动注册与发现，不再需要写死服务提供方地址，注册中心基于接口名查询服务提供者的IP地址，并且能够平滑添加或删除服务提供者。
Dubbo服务组件调用关秕说明：
Dubbo框架设计一共划分了10个层，而最上面的Service层是留给实际想要使用Dubbo开发分布式服务的开发者实现业务逻辑的接口层。
图中左边淡蓝背景的为服务消费方使用的接口，右边淡绿色背景的为服务提供方使用的接口，位于中轴线上的为双方都用到的接口。
下面，结合Dubbo官方文档，我们分别理解一下框架分层架构中，各个层次的设计要点：
从上图可以看出，Dubbo对于服务提供方和服务消费方，从框架的10层中分别提供了各自需要关心和扩展的接口，构建整个服务生态系统（服务提供方和服务消费方本身就是一个以服务为中心的）。
根据官方提供的，对于上述各层之间关系的描述，如下所示：
Dubbo协议
Dubbo是Alibaba开源的分布式服务框架远程调用框架，在网络间传输数据，就需要通信协议和序列化。
Dubbo支持dubbo、rmi、hessian、http、webservice、thrift、redis等多种协议，但是Dubbo官网是推荐我们使用Dubbo协议的，默认也是用的dubbo协议。
先介绍几种常见的协议：
缺省协议，使用基于mina1.1.7+hessian3.2.1的tbremoting交互。
连接个数：单连接
连接方式：长连接
传输协议：TCP
传输方式：NIO异步传输
序列化：Hessian二进制序列化
适用范围：传入传出参数数据包较小（建议小于100K），消费者比提供者个数多，单一消费者无法压满提供者，尽量不要用dubbo协议传输大文件或超大字符串。
适用场景：常规远程服务方法调用
1、dubbo默认采用dubbo协议，dubbo协议采用单一长连接和NIO异步通讯，适合于小数据量大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况
2、他不适合传送大数据量的服务，比如传文件，传视频等，除非请求量很低。
配置如下：
dubbo:protocolname=dubboport=/
dubbo:protocolname=“dubbo”port=“9090”server=“netty”client=“netty”codec=“dubbo”
serialization=“hessian2”charset=“UTF-8”threadpool=“fixed”threads=“100”queues=“0”iothreads=“9”
buffer=“8192”accepts=“1000”payload=“”/
3、Dubbo协议缺省每服务每提供者每消费者使用单一长连接，如果数据量较大，可以使用多个连接。
dubbo:protocolname=dubboconnections=2/
4、为防止被大量连接撑挂，可在服务提供方限制大接收连接数，以实现服务提供方自我保护
dubbo:protocolname=dubboaccepts=1000/
Java标准的远程调用协议。
连接个数：多连接
连接方式：短连接
传输协议：TCP
传输方式：同步传输
序列化：Java标准二进制序列化
适用范围：传入传出参数数据包大小混合，消费者与提供者个数差不多，可传文件。
适用场景：常规远程服务方法调用，与原生RMI服务互操作
RMI协议采用JDK标准的.*实现，采用阻塞式短连接和JDK标准序列化方式。
基于Hessian的远程调用协议。
连接个数：多连接
连接方式：短连接
传输协议：HTTP
传输方式：同步传输
序列化：表单序列化
适用范围：传入传出参数数据包大小混合，提供者比消费者个数多，可用浏览器查看，可用表单或URL传入参数，暂不支持传文件。
适用场景：需同时给应用程序和浏览器JS使用的服务。
1、Hessian协议用于集成Hessian的服务，Hessian底层采用Http通讯，采用Servlet暴露服务，Dubbo缺省内嵌Jetty作为服务器实现。
2、Hessian是Caucho开源的一个RPC框架：，其通讯效率高于WebService和Java自带的序列化。
基于http表单的远程调用协议。参见：[HTTP协议使用说明]
连接个数：多连接
连接方式：短连接
传输协议：HTTP
传输方式：同步传输
序列化：表单序列化
适用范围：传入传出参数数据包大小混合，提供者比消费者个数多，可用浏览器查看，可用表单或URL传入参数，暂不支持传文件。
适用场景：需同时给应用程序和浏览器JS使用的服务。
基于WebService的远程调用协议。
连接个数：多连接
连接方式：短连接
传输协议：HTTP
传输方式：同步传输
序列化：SOAP文本序列化
适用场景：系统集成，跨语言调用
序列化是将一个对象变成一个二进制流就是序列化，反序列化是将二进制流转换成对象
为什么要序列化？
Dubbo序列化支持java、compactedjava、nativejava、fastjson、dubbo、fst、hessian2、kryo，其中默认hessian2。
其中java、compactedjava、nativejava属于原生java的序列化。
hessian2序列化：hessian是一种跨语言的高效二进制序列化方式。
但这里实际不是原生的hessian2序列化，而是阿里修改过的，它是dubboRPC默认启用的序列化方式。
json序列化：目前有两种实现，一种是采用的阿里的fastjson库，另一种是采用dubbo中自己实现的简单json库，但其实现都不是特别成熟，而且json这种文本序列化性能一般不如上面两种二进制序列化。
java序列化：主要是采用JDK自带的Java序列化实现，性能很不理想。
阿里研发后开源，Dubbo成Apache基金会顶级项目
近日，基于Java的开源远程过程调用框架ApacheDubbo正在逐渐从Apache孵化器升级到顶级项目（TLP）。
该项目最初是由阿里开发的，并于2011年开源。
它于去年年初进入了Apache孵化器。
Apache软件基金会表示，Dubbo框架可以指定可跨分布式或微服务系统远程调用的方法，其主要功能是：基于接口的远程调用；容错和负载均衡；自动服务注册和发现。
最近加入TLP排名的其他项目包括基于标准的客户数据平台ApacheUnom和用于创建和管理大数据的可扩展工作流自动化和调度系统ApacheAirflow。
dubbo和eureka的区别
dubbo和springcloud区别是：
1、初始定位不同：
SpringCloud定位为微服务架构下的一站式解决方案；Dubbo是SOA时代的产物，它的关注点主要在于服务的调用和治理。
2、生态环境不同：
SpringCloud依托于Spring平台，具备更加完善的生态体系；而Dubbo一开始只是做RPC远程调用，生态相对匮乏，现在逐渐丰富起来。
3、调用方式：
SpringCloud是采用Http协议做远程调用，接口一般是Rest风格，比较灵活；Dubbo是采用Dubbo协议，接口一般是Java的Service接口，格式固定。
但调用时采用Netty的NIO方式，性能较好。
4、组件差异：
例如SpringCloud注册中心一般用Eureka，而Dubbo用的Zookeeper，SpringCloud生态丰富，功能完善，更像是品牌机，Dubbo则相对灵活，可定制性强，更像是组装机。
5、SpringCloud：
Spring公司开源的微服务框架，SpirngCloud定位为微服务架构下的一站式解决方案。
阿里巴巴开源的RPC框架，Dubbo是SOA时代的产物，它的关注点主要在于服务的调用，流量分发、流量监控和熔断。
两者的生态对比：
1、SpringCloud的功能很明显比Dubbo更加强大，涵盖面更广，而且作为Spring的旗舰项目，它也能够与SpringFramework、SpringBoot、SpringData、SpringBatch等其他Spring项目完美融合，这些对于微服务而言是至关重要的。
2、使用Dubbo构建的微服务架构就像组装电脑，各环节选择自由度很高，但是最终结果很有可能因为一条内存质量不行就点不亮了，总是让人不怎么放心。
3、而SpringCloud就像品牌机，在SpringSource的整合下，做了大量的兼容性测试，保证了机器拥有更高的稳定性，但是如果要在使用非原装组件外的东西，就需要对其基础原理有足够的了解。
目前比较流程的微服务开发框架是?
SpringBoot的设计目的是简化新Spring应用初始搭建以及开发过程，2017年有64.4%的受访者决定使用SpringBoot，可以说是最受欢迎的微服务开发框架。
利用SpringBoot开发的便捷度简化分布式系统基础设施的开发，比如像配置中心、注册、负载均衡等方面都可以做到一键启动和一键部署。
SpringCloud是一个系列框架的合计，基于HTTP（s）的RETS服务构建服务体系，SpringCloud能够帮助架构师构建一整套完整的微服务架构技术生态链。
Dubbo是由阿里巴巴开源的分布式服务化治理框架，通过RPC请求方式访问。
Dubbo是在阿里巴巴的电商平台中逐渐探索演进所形成的，经历过复杂业务的高并发挑战，比SpringCloud的开源时间还要早。
目前阿里、京东、当当、携程、去哪等一些企业都在使用Dubbo。
Dropwizard将Java生态系统中各个问题域里最好的组建集成于一身，能够快速打造一个Rest风格的后台，还可以整合Dropwizard核心以外的项目。
国内现在使用Dropwizard还很少，资源也不多，但是与SpringBoot相比，Dropwizard在轻量化上更有优势，同时如果用过Spring，那么基本也会使用SpringBoot。
Akka是一个用Scala编写的库，可以用在有简化编写容错、高可伸缩性的Java和Scala的Actor模型，使用Akka能够实现微服务集群。
.x/Lagom/ReactiveX/Spring5
这四种框架主要用于响应式微服务开发，响应式本身和微服务没有关系，更多用于提升性能上，但是可以和微服务相结合，也可以提升性能。
相关微服务框架
是专门针对模块化微服务架构设计的，是跨平台应用程序开发框架，是微软开发的第一个官方版本。
ServiceFabric是微软开发的一个微服务框架，基于ServiceFabric构建的很多云服务被用在了Azure上。
Surging是基于RPC协议的分布式微服务技术框架，基于而来。
MicrodotFramework用于编写定义服务逻辑代码，不需要解决开发分布式系统的挑战，能够很方便的进行MicrosoftOrleans集成。
微服务之架构技术选型与设计
本文主要介绍了架构技术选型与设计-微服务选型，Springcloud实现采用的技术，希望对您的学习有所帮助。
架构技术选型与设计-DUBBODubbo，是阿里巴巴服务化治理的核心框架，并被广泛应用于阿里巴巴集团的各成员站点(阿里巴巴现在使用架构为HSF)。于2012-10-24最后版本2.5.3成为最后一版本，由当当接手维护，命名为dubbox；2017年突然继续dubbo进行维护，最后更新版本时间为2017-10-1122:21
Dubbo核心部件:Provider：暴露服务的提供方。
Consumer：调用远程服务的服务消费方。
Registry：服务注册中心和发现中心。
Monitor：统计服务和调用次数，调用时间监控中心。
（dubbo的控制台页面中可以显示）Container：服务运行的容器。
Dubbo服务集群-集群容错模式
架构技术选型与设计-微服务选型
架构技术选型与设计-DUBBO
架构技术选型与设计-DUBBO
架构技术选型与设计-微服务选型SpringCloud，从命名我们就可以知道，它是SpringSource的产物，Spring社区的强大背书可以说是Java企业界最有影响力的组织了，除了SpringSource之外，还有Pivotal和Netfix是其强大的后盾与技术输出。
其中Netflix开源的整套微服务架构套件是SpringCloud的核心。
如果拿Dubbo与Netflix套件做对比，前者在国内影响力较大，后者在国外影响力较大，在背景上可以打个平手；但是若要与SpringCloud做对比，由于SpringSource的加入，在背书上，SpringCloud略胜一筹，但是在高并发上dubbo曾经在阿里的运营中实际承载过过亿用户同时在线的，而Netflix并没有实际的上线应用中体现过。
SpringCloud下面有19个子项目（可能还会新增）分别覆盖了微服务架构下的方方面面，服务治理只是其中的一个方面，一定程度来说，Dubbo只是SpringCloudNetflix中的一个子集。
但是在选择框架上，方案完整度恰恰是一个需要重点关注的内容，当然从高可用和高并发一起考虑，SpringCloud无疑是最佳选择。
1、SpringCloudConfig配置中心，利用git集中管理程序的配置。
2、SpringCloudNetflix集成众多Netflix的开源软件
3、SpringCloudBus消息总线，利用分布式消息将服务和服务实例连接在一起，用于在一个集群中传播状态的变化
4、SpringCloudforCloudFoundry利用PivotalCloudfoundry集成你的应用程序
5、SpringCloudCloudFoundryServiceBroker为建立管理云托管服务的服务代理提供了一个起点。
6、SpringCloudCluster基于Zookeeper,Redis,Hazelcast,Consul实现的领导选举和平民状态模式的抽象和实现。
7、SpringCloudConsul基于HashicorpConsul实现的服务发现和配置管理。
8、SpringCloudSecurity在Zuul代理中为OAuth2rest客户端和认证头转发提供负载均衡
9、SpringCloudSleuthSpringCloud应用的分布式追踪系统，和Zipkin，HTrace，ELK兼容。
10、SpringCloudDataFlow一个云本地程序和操作模型，组成数据微服务在一个结构化的平台上。
11、SpringCloudStream基于Redis,Rabbit,Kafka实现的消息微服务，简单声明模型用以在SpringCloud应用中收发消息。
12、SpringCloudStreamAppStarters基于SpringBoot为外部系统提供spring的集成
14、SpringCloudTaskAppStarters
15、SpringCloudZookeeper服务发现和配置管理基于ApacheZookeeper。
16、SpringCloudforAmazonWebServices快速和亚马逊网络服务集成。
17、SpringCloudConnectors便于PaaS应用在各种平台上连接到后端像数据库和消息经纪服务。
18、SpringCloudStarters（项目已经终止并且在2后的版本和其他项目合并
）19、SpringCloudCLI插件用Groovy快速的创建SpringCloud组件应用。SpringCloud共集成了19个子项目，里面都包含一个或者多个第三方的组件或者框架！
1、springcloud：一个云应用工具，为云应用开发的配置管理、服务发现、断路器、智能路由、微代理、控制总线、全局锁定、决策竞选、分布式会话和集群状态管理等操作
2、springcloudconfig：配置管理开发工具包
3、springcloudBus：事件消息总线用于集群（例如：配置变化时间）中传播状态变化，与springcloudconfig联合实现热部署
4、springcloudNetflixEureka：云端负载均衡基础，一个基于Rest的服务，用于定位服务，以实现云端的负载均衡和中间层服务器的故障转移
5、springcloudNetflixHystrix：容错管理工具，旨在通过控制服务和第三方库的节点，从而对延迟和故障提供更强大的容错能力
6、NetflixZUUL：边缘服务工具，提供动态路由、监控、弹性、安全等边缘服务
7、springcloudsleuth：日志收集工具包、封装Purpose、Zipkin和Trace
8、SpringCloudSecurity：安全工具包，为应用程序添加安全控制，主要是OAuth2
9、springcloudturbine：聚合服务器发送时间流，监控集群下Netflix和metrics情况
Springcloud配置中心
Springcloud注册中心
Springcloud网关:服务路由、安全认证、会话共享、客户端负载均衡、统一异常处理、跨域请求
Springcloud断路由
