CMDB的四种模式

为什么要有CMDB?

CMDB –Configuration Management Database 配置管理数据库.

1.为了实现资产的自动采集,资产的自动更新,

为了搭建公司自动化平台的基础则需要资产的管理.

2.优点减少了人工干预,降低人员成本.

 

CMDB三种工作方式

1.Agent
%title插图%num

Agent工作流程:

1.首先在每台服务器都装上agent. agent定时执行指令

2.agent将处理过的数据通过requests发给API

3.再由API更新到数据库中.

Ageng优点:

速度快;

缺点:

每一台服务器都需要Agent

 

 

2.ssh类

%title插图%num

 

ssh类的工作方式:

1.资产采集器(中控机)先向API获取未采集的服务器列表

2.中控机通过paramiko模块里的ssh远程连接到服务器.(主机名,密码,命令)获取服务器的数据

3.获取完所有未采集的服务器后,将数据发送给API.

 

优点:无agent

缺点:速度慢

适合用在服务器少的情况下.

 

3.salt-stack

 

%title插图%num

 

 

 

salt-stack流程:

1.安装了saltstack-master的中控机先去API获取未采集的主机名列表.

2.通过RPC的模式来获取数据.

(RPC模式:

将主机名,密码,命令放在a消息队列里

装有salstack-slave的服务器会去a消息队列里拿命令,检查是否是自己需要执行的.

服务器执行完命令后将数据放在b消息队列里,中控机去b消息队列里获取数据

zeromq软件)

3.将获取的数据发送给API,API存数数据库.

优点:速度快,开发成本低

缺点:依赖saltstack

 

4.puppet

1.要用ruby写.

2.有点自动汇报数据

缺点:必须用ruby

 

 

为什么要有API

1.提供接口.系统调用数据的时候,提供接口.不让外界直接接触数据库

2.对提交的数据进行统一化的管理.

3.比较安全.如果没有API如果服务器给黑了,可能会把数据库删表.

 

连接API的安全认证

1.API和服务器端各有一个相同的key

2.当服务器端想连接API的时候,将key进行md5加密,发给API

APi的key也进行MD5加密,两个密文对比.,相同则代表通过.

?存在问题. 如果这个key给别人截取了,那么其他的人就可以向API发无用的数据.

3.那么就让key动态起来,我利用了本地的时间和key组合成一个字符串,用md5加密同时也要将本地的时间发给API

因为API接收到的时间会延迟. 然后APIkey和服务端的时间,md5加密 然后两个密文对比.

?存在问题,发现有更多的key可以进入到API

4.将*次发送的密文放在一个列表里.第二次判断是否在该列表里,在则登录失败.

?那么需要存放的密文很多

5.失效.让服务器发的这个key10秒钟后时间,每次密文判断之前,先判断是否超时了.

清空失效的密文

 

%title插图%num %title插图%num

def api_auth_method(request):
    auth_key = request.META.get('HTTP_AUTH_KEY')
    if not auth_key:
        return False
    sp = auth_key.split('|')
    if len(sp) != 2:
        return False
    encrypt, timestamp = sp
    timestamp = float(timestamp)
    limit_timestamp = time.time() - ASSET_AUTH_TIME
    print(limit_timestamp, timestamp)
    if limit_timestamp > timestamp:
        return False
    ha = hashlib.md5(ASSET_AUTH_KEY.encode('utf-8'))
    ha.update(bytes("%s|%f" % (ASSET_AUTH_KEY, timestamp), encoding='utf-8'))
    result = ha.hexdigest()
    print(result, encrypt)
    if encrypt != result:
        return False

    exist = False
    del_keys = []
    for k, v in enumerate(ENCRYPT_LIST):
        print(k, v)
        m = v['time']
        n = v['encrypt']
        if m < limit_timestamp:
            del_keys.append(k)
            continue
        if n == encrypt:
            exist = True
    for k in del_keys:
        del ENCRYPT_LIST[k]

    if exist:
        return False
    ENCRYPT_LIST.append({'encrypt': encrypt, 'time': timestamp})
    return True

浅谈对service mesh 的一点点理解

原来使用的istio对应的版本为0.8,还只是在kubernetes没有落地的环境下使用,可以解决现在微服务框架下的服务注册与发现、身份验证与授权,熔断(过载保护),降级,流量控制等功能。

有人说“有了ISTIO,你的服务就不再需要任务微服务开发框架(springcloud ,dubbo的框架对服务治理,需要自己手动写程序处理)了!”

现在已发布了istio v1.0版本,并且官方说可以直接使用于生产环境,又基于我使用的是kubernetes环境,并且一直以为它是对kubernetes支持*好的,真是欣喜甚慰!

istio = 微服务框架 + 服务治理

istio的关键特性:

  • HTTP/1.1,HTTP/2,gRPC和TCP流量的自动区域感知和故障切换;
  • 路由规则丰富,容错和故障注入,对流行为提供细粒度控制;
  • 支持访问控制,速率限制和配额的可插拔和配置API;
  • 集群内所有流量的自动量度,日志和跟踪,包括 集群INGRESS和ENGRESS;
  • 安全的服务到服务身份验证;

没有service mesh前,微服务对运维带来了什么?

解耦的各个服务,可能多达几十上百个,怎么管理各个服务之间的连接,部署,版本控制,安全,故障转移,微略执行,遥测和和监控等,更不说常见的A/B测试。金丝雀发布 ,限流,访问控制,端对端认证。

痛点:

“找个Spring Cloud或者Dubbo的成熟框架,直接搞定服务注册,服务发现,负载均衡,熔断等基础功能。然后自己开发服务路由等高级功能, 接入Zipkin等Apm做全链路监控,自己做加密、认证、授权。 想办法搞定灰度方案,用Redis等实现限速、配额。 诸如此类,一大堆的事情, 都需要自己做,无论是找开源项目还是自己操刀,*后整出一个带有一大堆功能的应用程序,上线部署。然后给个配置说明到运维,告诉他说如何需要灰度,要如何如何, 如果要限速,配置哪里哪里。”—转载自数人云

service mesh是基础设施层,轻量级高性能网络代理,对应用透明。

 

%title插图%num

然,Istio也可以视为是一种服务网格。

  • 数据面板由一组智能代理(Envoy)组成,代理部署为边车(sidecar),调解和控制微服务之间所有的网络通信。
  • 控制面板负责管理和配置代理来路由流量,以及在运行时执行策略。

istio的架构图如下:

 

%title插图%num

它让开发专注于业务逻辑的处理和实现!

关于对envoy,pilot,mixer,auth的各个模块的介绍,可去数人云了解。

有了微服务和云原生,为什么还要懂Service Mesh?

Service Mesh技术作为新一代微服务架构,有效的解决了当前微服务架构和治理过程中的痛点问题,一经推出便引起很大的反响,近两年持续成为架构领域的热点。特别是Google联合Lyft等公司推出的Istio,架构优雅,功能强大,迅速成为Service Mesh领域的明星项目。

什么是Service Mesh
作为Service Mesh技术探索和实践的先行者,全球*个真正的Service Mesh项目Linkerd负责人、Buoyant公司创始人兼CEO William Morgan*次完整地阐述了Service Mesh。按照William Morgan的定义,Service Mesh是一个致力于解决服务间通信的基础设施层,其负责在现代云原生应用的复杂服务拓扑下实现请求的可靠传递,在实践中Service Mesh通常实现为一组轻量级网络代理,这些代理与应用程序部署在一起,并且对应用程序透明。

从上述Service Mesh的定义看,基础设施层是Service Mesh的定位,致力于解决本书第1章提出的微服务基础设施标准化、配置化、服务化和产品化问题;服务间通信是Service Mesh技术面对的问题域,对微服务屏蔽通信的复杂度,解决微服务的通信治理问题;请求的可靠传递是Service Mesh的目标;轻量级网络代理是Service Mesh的部署方式;对应用程序透明是Service Mesh的亮点和特色,Service Mesh接入对业务无侵入,可以非常方便地获取Service Mesh带来的便捷性,算是Service Mesh的一大优势。

综合来看,Service Mesh主要解决用户如下3个维度的痛点需求。

完善的微服务基础设施
Service Mesh通过将微服务通信下沉到基础设施层,屏蔽了微服务处理各种通信问题的复杂度,可以看成是微服务之间的抽象协议层,抽象层面可以看成是TCP/IP协议栈的一部分。对于微服务的开发者来说,比如当前使用HTTP或者Thrift进行RPC通信时,你不需要关注TCP/IP这一层的具体实现;有了Service Mesh之后,微服务也不再需要关注RPC通信(包含服务发现、负载均衡、流量调度、限流降级、监控统计等)的一切细节,真正像本地调用一样使用微服务,通信相关的一切工作直接交给Service Mesh。

因此,对于一些需要通过微服务改造提升业务敏捷性,但没有相应技术能力的中小团队来说,可以借助Service Mesh提供的完善微服务基础设施,加速微服务的落地。

语言无关的通信和链路治理
功能上,Service Mesh并没有提供任何新的特性和能力,Service Mesh提供的所有通信和服务治理能力在Service Mesh之前的技术中均能找到,比如Spring Cloud就实现完善的微服务RPC通信和服务治理支持。Service Mesh改变的是通信和服务治理能力提供的方式,通过将这些能力实现从各语言业务实现中解耦,下沉到基础设施层面,以一种更加通用和标准化的方式提供,屏蔽不同语言、不同平台的差异性,这样不仅有利于通信和服务治理能力的迭代和创新,业务使用的时候也会更加方便。

Service Mesh避免了多语言服务治理上的重复建设,通过Service Mesh语言无关的通信和服务治理能力,助力多语言技术栈的效率提升。

通信和服务治理的标准化
微服务治理层面,Service Mesh是标准化、体系化、无侵入的分布式服务治理平台。
标准化方面,Sidecar成为所有微服务流量通信的约束标准,同时Service Mesh的数据平面和控制平面也通过标准协议进行交互。
体系化方面,从全局考虑,提供多维度立体的微服务可观测能力(Metric、Trace、Logging),并且提供体系化的服务治理能力,比如限流、熔断、安全、灰度等;*为重要的是,Service Mesh通过透明无侵入的方式提供全面的服务治理能力,对微服务本身不会带来直接影响。
通过标准化,带来一致的服务治理体验,减少多业务之间由于服务治理标准不一致带来的沟通和转换成本,提升全局服务治理的效率。

Service Mesh的基本模式
根据Service Mesh的发展历程和使用方式,我们可以把Service Mesh划分为两个模式。

Sidecar模式
在Service Mesh发展早期,Service Mesh以Sidecar的形态存在。Sidecar模式下,网络代理服务在微服务旁边,为微服务提供通信和链路治理功能。因此,数据平面代理服务也经常被简称为Sidecar。

此时,只有数据平面的网络代理服务没有控制平面,和外部基础设施服务的交互直接在网络代理服务中进行。

Sidecar模式可以看作是*代Service Mesh,代表有早期的Linkerd和Envoy。

*代Service Mesh通过采用Sidecar模式,通过将通信和通信链路治理功能从微服务中剥离出来,实现了通信基础设施的下沉和服务化,这里也体现了架构解耦的思想,通过解耦减少了微服务的负担。

第二代Service Mesh模式
Sidecar模式的Service Mesh有一个突出的问题,将通信和通信链路治理的所有功能都放到这个代理服务中,导致数据平面代理很重,并且由于承载了太多的特性和功能,使得数据平面代理的更新和修改特别频繁,频繁的更新和升级会导致代理服务出问题的概率增大,影响代理服务的稳定性。同时,Service Mesh模式下,数据平面代理承载了微服务通信的全部流量,对稳定性要求*高,这个服务的任何故障都会对整个系统的稳定性产生很大的影响。为了解决上述频繁升级和稳定性之间的矛盾,将策略和配置决策逻辑从代理服务中脱离出来,形成了独立的控制平面,这就是第二代Service Mesh。

第二代Service Mesh*重要的标志就是控制平面和数据平面分离。数据平面和控制平面并不是新的概念,路由器/交换机等数据通信产品架构上,就有运行于专门处理器上的控制平面和多个独立运行、用于路由或交换功能的数据平面。SDN(Software Defined Network,软件定义网络)将数据平面和控制平面分离,控制平面具有可编程性,使得网络更加智能、灵活和易扩展,激发了网络技术的又一次革命。

第二代Service Mesh借鉴了SDN的思路,基于控制平面和数据平面分离思想,有了完善的控制平面:①所有的代理服务都由控制平面掌控,因为控制平面可以控制整个系统,所以提供了强大的控制能力和策略能力;②将具体的控制逻辑从数据平面移除,简化了数据平面的设计,数据平面不需要和外部系统进行交互,数据平面完全聚焦在变更频率很低的流量路由和转发逻辑上,提升了数据平面的稳定性。

Service Mesh架构
第二代Service Mesh的基本架构上分为数据平面和控制平面两个部分,大致如下图所示。
%title插图%num

数据平面
数据平面负责代理微服务之间的通信,具体包含RPC通信、服务发现、负载均衡、降级熔断、限流容错等,数据平面可以认为是将Spring Cloud、Dubbo等语言相关的微服务框架中通信和服务治理能力独立出来的一个语言无关的进程,并且更注重通用性和扩展性。在Service Mesh中,不再将数据平面代理视为一个个孤立的组件,而是将这些代理连接在一起形成一个全局的分布式网络。

控制平面
控制平面负责对数据平面进行管理,定义服务发现、路由、流量控制、遥测统计等策略,这些策略可以是全局的,也可以通过配置某个数据平面节点单独指定。控制平面通过一定的机制将策略下发到各个数据平面节点,数据平面节点在通信时会使用这些策略。
————————————————

原文链接:https://blog.csdn.net/xingduan5153/article/details/103085259

鸟瞰微服务、云原生、容器和无服务器(一)

本系列文章希望对现代软件行业的一些关键主题,即微服务、云原生应用程序、容器和无服务器应用程序提供实践性支持,并涵盖这些技术的实际优点和缺点。

这一系列文章由《Golang Cloud Native编程》一书的作者Mina Andrawos撰写——该书为云原生微服务提供了实用技术和架构模式。他还是《 掌握Go编程》和《现代Golang编程》视频课程的作者。

本系列文章希望对现代软件行业的一些关键主题,即微服务、云原生应用程序、容器和无服务器应用程序提供实践性支持,并涵盖这些技术的实际优点和缺点。

微服务

微服务架构作为构建现代软件应用程序的强大方法赢得了业内认同。什么是微服务?微服务将软件应用所需的功能分成多个独立的小软件服务。这些微服务中的每一个都负责一个专门的任务。为了使这些微服务一起工作以形成一个大型可扩展应用程序,它们必须在多个服务器之间进行通信和交换数据,这被称为水平扩展。

每个服务都可以部署在具有专用资源的不同服务器上,也可以部署在不同的容器中。这些服务可以用不同的编程语言编写,实现更大的灵活性,并允许每个团队专注于单个服务,*终得到质量更高的应用程序

使用微服务的另一个显著优势是易于持续交付,或经常和随时部署软件的能力。微服务使得持续交付更容易,因为部署到一个微服务的新功能不太可能影响其他微服务。

云原生应用

 


微服务架构非常适合云原生应用程序——从云计算基础开始构建的应用程序。如果设计为可在分布式和可伸缩的基础设施上进行部署,那么应用程序就是云原生的。

例如,构建具有冗余微服务架构的应用程序使应用程序成为云原生的,因为此架构允许应用程序以分布式的方式进行部署,从而使其可扩展且几乎总是可用。云原生应用程序不需要总是部署到公有云(如AWS),也可以部署到分布式云类基础设施。

实际上,使应用程序完全云原生的原因不仅仅在于使用微服务。你的应用程序应该采用持续交付,能够在不中断的情况下持续向生产应用程序提供更新。你的应用程序还应该使用消息队列和容器等技术。

云原生应用程序假定可以访问众多的服务器节点,可以访问预先部署的软件服务,如消息队列或负载均衡器,易于与持续交付服务集成等。

如果你将云原生应用程序部署到AWS或Azure等商业云,你的应用程序可以选择使用只有在云中才有的软件服务。例如,DynamoDB是一个功能强大的数据库引擎,只能在AWS上用于生产应用程序。另一个例子是Azure中的DocumentDB数据库。还有像Amazon Simple Queue Service(SQS)这样的云消息队列,可用于允许AWS云中微服务之间的通信。

如前所述,云原生微服务应该被设计为允许服务之间的冗余。如果我们以事件预订应用程序为例,应用程序将如下所示:

%title插图%num

每个微服务将分配多个服务器节点,从而部署冗余的微服务架构。如果主节点或服务因任何原因失败,则辅助节点可以接管,以确保云原生应用的持久可靠性和可用性。这种可用性对于电子商务平台等容错应用程序至关重要,因为电子商务平台的停机时间会导致收入损失。

在微服务和云计算领域一个值得一提的工具是Prometheus。Prometheus是一个开源的系统监控和警报工具,可用于监控复杂的微服务架构,并在需要采取行动时发送警报。Prometheus*初由SoundCloud创建来监控其的系统,现在逐渐发展为一个独立的项目,并成为CNCF的一部分。

容器

一个容器就是将一些软件封装在一个孤立的用户空间或“容器”中的想法。例如,一个MySQL数据库可以在一个容器内隔离,其中有所需要的环境变量和配置。默认情况下,容器外部的软件将不会看到容器内包含的环境变量或配置。同一个本地虚拟机、云虚拟机或硬件服务器上可以存在多个容器。

容器提供了在同一台计算机上运行众多独立软件服务及其所有配置、软件依赖关系、运行时、工具和附带文件的功能。在云环境中,这种能力转化为成本和功夫的节省,因为为每个微服务供应和购买服务器节点的需求会减少( 不同的微服务可以部署在同一主机上而不会相互干扰)。容器与微服务架构相结合,成为构建现代、便携、可扩展且经济高效软件的强大工具。在生产环境中,需要多个服务器节点和众多容器来实现可扩展性和冗余。

容器为云原生应用程序增加了更多优势。使用容器,你可以将微服务及其所需的所有配置、依赖关系和环境变量移动到全新的服务器节点上,而无需重新配置环境,这样就实现了强大的可移植性。

由于软件容器技术的强大和普及,一些新的操作系统,如CoreOS或Photon OS,从一开始就为容器的主机而构建。

Docker是软件行业*受欢迎的软件容器项目之一。思科、谷歌和IBM等公司在其基础设施和产品中使用Docker容器。

Kubernetes是软件容器领域的另一个值得关注的项目。Kubernetes是一个允许自动化部署、管理和伸缩容器的工具。为了便于管理其容器,谷歌建立了Kubernetes。它提供了一些强大的功能,例如容器之间的负载均衡,重启失败的容器以及编排容器使用的存储。

云原生计算的缺点

指出这些技术的缺点非常重要。严重依赖微服务的一个显著缺点是,随着数量和范围的扩大,*终它们可能变得太复杂而无法管理。有一些方法可以缓解,如利用诸如Prometheus的监视工具来检测问题和诸如Docker之类的容器技术避免污染主机环境并避免过度设计服务。但是,这些方法需要付出努力和时间。

对于云原生应用程序,如果需要迁移部分或全部应用程序,则会面临一些挑战。这有多种原因,具体取决于应用程序的部署位置。

一个原因是如果你的云原生应用程序部署在像AWS这样的公有云上,云原生API不是跨云平台的。例如,应用程序中使用的DynamoDB数据库API仅适用于AWS,而不适用于Azure,因为DynamoDB仅属于AWS。这一API也不会在本地环境中工作,因为DynamoDB只能在生产环境中使用AWS。

另一个原因是,构建一些云原生应用程序时会做出一些假设,例如在需要时实际上可以使用无限数量的服务器节点,并且可以快速提供新的服务器节点。但是在需要购买服务器、网络硬件和布线的本地数据中心环境中,这些假设有时难以保证。

就容器而言,由于与管理不断扩大微服务数量相同的原因,管理容器有时会变得相当复杂。随着容器或微服务的规模不断扩大,需要有一种机制来确定每个容器或微服务的部署位置、目的是什么以及它们需要什么资源才能继续运行。

无服务器应用

无服务器架构是一种新的软件架构范式,已通过AWS Lambda服务推广。为了完全理解无服务器应用,我们首先定义功能即服务(FaaS)。这是一个云提供商(如亚马逊或甚至本地软件,如Fission.io或funktion)提供服务的想法,用户可以请求一个远程运行的功能以执行非常特定的任务,然后在功能结束后,功能结果会返回给用户。不需要维护服务或有状态数据,功能代码由用户提供给运行该功能的服务。

利用无服务器架构设计合理的生产应用程序的想法是,不是构建多个持续运行的微服务来执行单个任务,而是构建一个有更少的与FAAS结合的微服务的应用来完成不需要服务持续运行的任务

FAAS的构造比微服务更小。例如,对于之前介绍的事件预订应用程序,有多个微服务覆盖不同的任务。如果我们使用无服务器应用模型,那么这些微服务中的一些将被替换为许多服务于其目的的功能。例如,下面的图表展示了使用无服务器架构的应用程序:

%title插图%num

个现有的微服务。

这种单体的应用程序将适用于小到中等负载。它可以在单个服务器上运行,连接到单个数据库,并且可能会用相同的编程语言编写。

那么,如果业务繁多以及数十万或数百万用户需要处理,会发生什么?*初,短期解决方案是确保运行应用程序的服务器具有强大的硬件规格,以承受更高的垂直伸缩负载(增加硬件规格的方法包括用RAM和硬盘驱动器运行繁重应用程序)。通常情况下,随着应用程序的负载持续增长,这种方法不可持续。

单体应用的另一个挑战是由于仅限于一种或两种编程语言而导致的不灵活性。这种不灵活性会影响应用程序的整体质量和效率。例如,node.js是用于构建Web应用程序的流行JavaScript框架,而R在数据科学应用程序中很受欢迎。一个单体的应用程序很难同时使用这两种技术,而在微服务应用程序中,你可以简单地构建用R编写的数据科学服务和用Node.js编写的Web服务。

单体应用的第三个大挑战是协作。例如,在事件预订应用程序中,修改在单个前端用户接口层中的bug可能会影响其他应用程序,如搜索、事件和预订处理程序。

如果你要创建事件应用程序的微服务版本,它将采用以下形式:

%title插图%num

此应用程序将能够在多个服务器之间进行水平缩放。每个服务都可以部署在具有专用资源的不同服务器上,或者部署在不同的容器中。

微服务如何与云原生应用程序一起工作?


微服务架构非常适合云原生应用程序。云原生应用程序简单地定义为从底层构建并运行在云平台上的应用程序。云平台具有许多优点,例如在免去IT硬件基础设施规划痛苦的情况下,就可以立即获得多个服务器节点。在微服务架构中构建应用程序是开发可扩展的云原生应用程序的重要一步。

云原生应用程序的另一个功能是利用只有在云上才有的软件服务。例如,DynamoDB是一种功能强大的数据库引擎,只能在AWS上用于生产应用程序。另一个例子是Azure中的DocumentDB数据库。还有云原生消息队列,如Amazon Simple Queue Service(SQS),可用于允许AWS云中微服务之间的通信。

云原生微服务也可以设计为允许服务之间的冗余。如果以事件预订应用程序为例,该应用程序将如下所示:

%title插图%num

由于获得新的服务器节点不是硬件基础设施的挑战,因此可以为每个微服务分配多个服务器节点。如果主节点或服务出于任何原因失败,辅助节点可以接管,从而确保云本机应用的持久可靠性和可用性。这里的关键是可用于容错应用程序,如电子商务平台,其中停机时间会导致收入损失。

微服务云原生应用程序将微服务的优势与云计算的优势相结合,为开发人员、企业和创业公司提供巨大的价值。

另一个显著优势(除了可用性和可靠性)是持续交付。微服务使持续交付更容易的原因是因为部署到一个微服务的新功能不太可能影响其他微服务。

结论

云计算为开发高效、可扩展和可靠的软件开辟了道路。在这里,我们介绍了云计算领域的一些重要概念,如微服务、云原生应用和无服务器应用。

在设计应用程序时,架构师必须选择是构建单体应用程序、微服务云原生应用程序或是无服务器应用程序。

在本系列的第二篇文章中,我们将深入介绍云原生应用程序和容器,以及它们的缺点。本系列的第三部分将详细介绍无服务器应用程序,并展示如何将以上三者结合在一起。

miui+ 的同步原理是依靠 WIFI 局域网吗?

miui+ 的同步原理是依靠 WIFI 局域网吗?

还是蓝牙?或是走公网?

15 条回复    2021-01-27 13:50:00 +08:00
Atomo
    1

Atomo   102 天前   ❤️ 1

目测是局域网,
另华为的多屏协同是蓝牙认证,拉起 wifi,走自己的 wlan 修改版协议
yayiji
    2

yayiji   102 天前

笔记我看可以直接走公网,文件照片什么的,还不太清楚
systemcall
    3

systemcall   102 天前 via Android

目测是先蓝牙配对,其中一个设备 WiFi 开个热点,通过蓝牙通知另一个来连接。之后哪怕直接走 adb 都没有问题,功能不算很复杂,有很多开源的轮子,而且华为和联想、微软*近都有类似的东西
echo314
    4

echo314   102 天前   ❤️ 1

wifi direct ?
NSAgold
    5

NSAgold   102 天前

应该是类似 scrcpy 的实现(纯猜测) *终肯定是走 wifi 蓝牙那点可怜的带宽不够的
felixlong
    6

felixlong   102 天前 via Android

@Atomo 都是蓝牙拉起 miracast 啦。各家应该没什么差别。
wysnylc
    7

wysnylc   102 天前

首先排除公网
natashahollyz
    8

natashahollyz   102 天前 via iPhone

WiFi
Atomo
    9

Atomo   101 天前

@felixlong #6 我刚刚试了华为,手机忘记 wifi 密码,电脑客户端通过蓝牙拉起手机的 wlan,可以实现多屏协同,手机始终没有连接路由器的 wifi,但必须要打开 wlan 开关
ciaoly
    10

ciaoly   101 天前 via Android

楼上说了,是 WiFi direct 和 miracast
JayFang1993
    11

JayFang1993   101 天前

有 Mac 版吗?发布会上好像只看到 Windows
ETO
    12

ETO   99 天前

我电脑手机不连 wifi 也能使用,我猜应该是手机内自己开的热点吧。
ETO
    13

ETO   99 天前

@Atomo 对的,我用的小米 10 也是这样的。
systemcall
    14

systemcall   99 天前

@ciaoly miracast 本身就是蓝牙+WiFi Direct,那个东西只是解决了无线显示和输入
传输文件、打开应用,猜测是走的网络协议,这个只要包可以发过去就可以了,哪怕走蓝牙都可以。估计会因为实现难度和实际效果,限制成走 WiFi,同局域网和 WiFi Direct 因为网络状态变化要做一些适配。公网只做一下日历、便签和照片同步,走的手机厂家自己的云服务,和手机没多大关系
@ETO 应该是用蓝牙拉起的配对,Miracast 就是支持用蓝牙拉起的,AirDrop 没记错的话也是
hao150
    15

hao150   73 天前

走的是 WIFI 。如果电脑没有 WIFI 的话是没办法使用的

如何证明这个服务器有问题?

1 cuixiao603 · 221 天前 · 3214 次点击
这是一个创建于 221 天前的主题,其中的信息可能已经有所发展或是发生改变。
公司项目用了某小公司的云服务器( 8 核 16g ),使用过程出现各种奇奇怪怪问题。

1.启动 springboot 的 jar 包,正常服务器启动完成只需 2 、3 秒,但是在这台服务器上非常慢,需要 1 分 42 秒(日志输出 spring 那几个大字母就要好几秒,输出完 spring 就是漫长的等待直到开始输出日志)
2.接口响应时间间歇性的非常慢,正常请求不到 1 秒的接口,有时候会响应 20 多秒甚至超时。
3.一句稍微复杂的 sql,在本地笔记本的 mysql 上只需 1 、2 秒就执行。在服务器上的 mysql 需要十几秒的查询时间。
这个速度甚至不如我们自己笔记本。可以用什么软件来测试一下证明这台服务器有问题呢(或者是证明是我们软件层面的问题)

服务器 MySQL spring 日志29 条回复 • 2020-09-17 05:00:53 +08:00
soji18 1
soji18 221 天前 via Android
跑分?
xflcx1991 2
xflcx1991 221 天前 ❤️ 1
难道不是在这个服务器上做一套 Benchmark 吗?
laminux29 3
laminux29 221 天前 ❤️ 1
跑分软件不就是为这种场景准备的吗?

CPU 、内存、存储设备等,跑一次分就知道了。
xooass 4
xooass 221 天前
某小公司? 不会就是那种租台服务器+买个 VPS 面板就开卖的吧,那种稳定性纯靠运气
superrichman 5
superrichman 221 天前 via iPhone ❤️ 1
盲猜服务器 dns 配置有问题
buliugu 6
buliugu 221 天前
这个超卖的有点过分啊
cuixiao603 7
cuixiao603 221 天前
@xooass #4 哈哈 这个倒不是,就是某公司的云服务外包给某大公司来建设的那种,但是这个大公司的技术也不怎么样
cuixiao603 8
cuixiao603 221 天前
@superrichman #5 能详细说说吗,是我本地的 dns 配置问题吗
hasdream 9
hasdream 221 天前 ❤️ 1
启动慢? FQDN 是不是没有设置 `time hostname -f ` 看需要多久。 觉得性能有问题就跑个分看下 Unixbench
lv2016 10
lv2016 221 天前
关于第三点:我自己电脑的运行速度确实比我阿里云(4c8g)的服务器快

594duck 11
594duck 221 天前 ❤️ 1
Spring 包又需要解 DNS

怀疑是服务器超售 CPU 同时磁盘 IO 不够

启动 Spring 包这么久,开二个 terminal 看一下 cpu 耗时和 idle,*重要的是 load average, NI, SI, WA 。
594duck 12
594duck 221 天前
Spring 包又不需要解 DNS

又不是 SSH 慢,因为 DNS 反解,别瞎走方向。

先看系统各 IO 层面。
cuixiao603 13
cuixiao603 221 天前
@hasdream #9 time hostname -f 很快 毫秒级的
cuixiao603 14
cuixiao603 221 天前
@lv2016 #10 哈哈 我还拿这个服务器和阿里云的 1 核服务器对比了,阿里云的很快的
AstroProfundis 15
AstroProfundis 221 天前
石头盘吧
DJQTDJ 16
DJQTDJ 221 天前 ❤️ 1
*机器配置
第二目前 cpu 内存使用率
第三网络环境
narmgalaxy 17
narmgalaxy 221 天前
盲猜是 mysql 相关的问题
dilu 18
dilu 221 天前 ❤️ 2
提供个方法

用 strace 看一下系统调用 再用-c 参数看看系统调用的统计

看看时间*长的系统调用是哪个

然后再有针对性的去排查 CPU 内存 磁盘 网络这几个方向
opengps 19
opengps 221 天前
具体问题需要找到具体制约因素,比如说硬盘慢,比如说 cpu 不够
单纯迁移过来表现不佳,没法归咎于“服务器问题”。分享个我的例子:*近给客户做的项目,明确要求如果使用云服务器硬盘则必须使用 ssd,但是对方一句我程序性能有问题,不服,我给他买了 ssd 换上立刻解决,当场打脸,对方不说话了
opengps 20
opengps 221 天前 ❤️ 2
楼层里有人提到超卖,这也是笼统不负责任的找答案方式,虽然不排除存在这个可能导致的,但是并不一定就是当前问题的根本原因
几乎所有云服务器都是虚拟机,而虚拟机有个天生的缺陷就是硬盘的 io 损失巨大(我测算过 1k 块大小的 iops 指标,只能达到原来物理硬盘的十分之一)
楼主可以先尝试下买个单独的 ssd 硬盘挂上,看下测试结果,在明确说下是不是硬盘问题,不建议直接说成“服务器问题”这么笼统的概念
jeeyong 21
jeeyong 221 天前
找台笔记本跑同样的项目.
笔记本没有类似的问题.就是他的问题.
如果领导坚持不换, 他就是吃回扣了..
告他. 骂他. 被公司解雇就继续骂领导, 骂公司.
自己开发自动发贴机, 天天各大论坛渠道发帖骂他…
Ayahuasec 22
Ayahuasec 221 天前
这个性能表现让我想起来,去年有个我同学用 qemu 跑 debian,结果速度巨慢,虚拟机都快分配了所有资源了还是很慢,测试程序的时候主机半分钟能跑完但是虚拟机里要快 5 分钟才能跑完,*后我们两个来回排查发现他 kvm 没开……
cuixiao603 23
cuixiao603 221 天前
@narmgalaxy #17
应该不是吧 springboot 刚开始启动还没开始连数据库呢
cuixiao603 24
cuixiao603 221 天前
@jeeyong #21 哈哈 说出你的故事啊老哥
CallMeReznov 25
CallMeReznov 221 天前
云系统*容易出问题的环节就是磁盘

建议看下 iostat 对比一下就知道了
jeeyong 26
jeeyong 220 天前
@cuixiao603 没啥故事…和领导吵架, 告公司, 攻击公司业务服务器…
现在公司黄了, 我待业在家..就这样.
bitholic 27
bitholic 220 天前
可能是系统熵(entropy)太低了,导致 tomcat 启动太慢,加个-Djava.security.egd=file:/dev/./urandom 试试?
theqwang 28
theqwang 220 天前
建议先测试一下服务器 IO 性能,多半 IO 有问题
nuk 29
nuk 205 天前
十有八九内存分超了,测试一下内存读写速度就知道了

Android 11 系统上 Okhttp 3.10 版本

Android 11 系统上 Okhttp 3.10 版本上部分手机出现 Java .lang.VerifyError:Superclass okhttp3.internal.http1.Http1Codec$AbstractSource

Caused by:
5 java.lang.VerifyError:Superclass okhttp3.internal.http1.Http1Codec$AbstractSource of okhttp3.internal.http1.Http1Codec$UnknownLengthSource is declared final (declaration of ‘okhttp3.internal.http1.Http1Codec$UnknownLengthSource’

appears in /data/app/~~7Slsz0eTU_atlqLyl7NGKQ==/com.zhenhui.huilianyi-5gJPwjBAIcieNSC9WYPr4g==/base.apk)
6 okhttp3.internal.http1.Http1Codec.f(Http1Codec.java:259)
7 okhttp3.internal.http1.Http1Codec.a(Http1Codec.java:153)
8 okhttp3.internal.http.CallServerInterceptor.intercept(CallServerInterceptor.java:124)
9 okhttp3.internal.http.RealInterceptorChain.a(RealInterceptorChain.java:147)
10 okhttp3.internal.http.RealInterceptorChain.a(RealInterceptorChain.java:121)
11 com.huilianyi.hlybaselibrary.http.HttpClientManager$1.intercept(HttpClientManager.java:39)
12 okhttp3.internal.http.RealInterceptorChain.a(RealInterceptorChain.java:147)
13 okhttp3.internal.connection.ConnectInterceptor.intercept(ConnectInterceptor.java:45)
14 okhttp3.internal.http.RealInterceptorChain.a(RealInterceptorChain.java:147)
15 okhttp3.internal.http.RealInterceptorChain.a(RealInterceptorChain.java:121)
16 okhttp3.internal.cache.CacheInterceptor.intercept(CacheInterceptor.java:93)
17 okhttp3.internal.http.RealInterceptorChain.a(RealInterceptorChain.java:147)
18 okhttp3.internal.http.RealInterceptorChain.a(RealInterceptorChain.java:121)
19 okhttp3.internal.http.BridgeInterceptor.intercept(BridgeInterceptor.java:93)
20 okhttp3.internal.http.RealInterceptorChain.a(RealInterceptorChain.java:147)
21 okhttp3.internal.http.RetryAndFollowUpInterceptor.intercept(RetryAndFollowUpInterceptor.java:126)
22 okhttp3.internal.http.RealInterceptorChain.a(RealInterceptorChain.java:147)
23 okhttp3.internal.http.RealInterceptorChain.a(RealInterceptorChain.java:121)
24 com.huilianyi.hlybaselibrary.http.intercept.HttpInterceptor.intercept(HttpInterceptor.java:63)
25 okhttp3.internal.http.RealInterceptorChain.a(RealInterceptorChain.java:147)
26 okhttp3.internal.http.RealInterceptorChain.a(RealInterceptorChain.java:121)
27 okhttp3.RealCall.i(RealCall.java:200)
28 okhttp3.RealCall.b(RealCall.java:77)
29 retrofit2.OkHttpCall.execute(OkHttpCall.java:180)
30 retrofit2.adapter.rxjava.RxJavaCallAdapterFactory$RequestArbiter.request(RxJavaCallAdapterFactory.java:171)
31 rx.internal.operators.OperatorSubscribeOn$1$1$1.request(OperatorSubscribeOn.java:80)
32 rx.Subscriber.setProducer(Subscriber.java:209)
33 rx.internal.operators.OperatorSubscribeOn$1$1.setProducer(OperatorSubscribeOn.java:76)
34 rx.Subscriber.setProducer(Subscriber.java:205)
35 retrofit2.adapter.rxjava.RxJavaCallAdapterFactory$CallOnSubscribe.call(RxJavaCallAdapterFactory.java:152)
36 retrofit2.adapter.rxjava.RxJavaCallAdapterFactory$CallOnSubscribe.call(RxJavaCallAdapterFactory.java:138)
37 rx.internal.operators.OnSubscribeLift.a(OnSubscribeLift.java:50)
38 rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:30)
39 rx.Observable.a(Observable.java:8666)
40 rx.internal.operators.OperatorSubscribeOn$1.call(OperatorSubscribeOn.java:94)
41 rx.internal.schedulers.CachedThreadScheduler$EventLoopWorker$1.call(CachedThreadScheduler.java:220)
42 rx.internal.schedulers.ScheduledAction.run(ScheduledAction.java:55)
43 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:462)
44 java.util.concurrent.FutureTask.run(FutureTask.java:266)
45 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:301)
46 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
47 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
48 java.lang.Thread.run(Thread.java:923)

 

2 条回复    2021-01-08 16:14:07 +08:00

chenjiajia9411
    1

chenjiajia9411   93 天前

混淆有问题,AbstractSource 给弄成 final 了,把 allowaccessmodification 关了,以后上传的日志*好也带上符号表或者直接还原不然不方便看。
还有如果还需要兼容 API 21 以下就把 OkHttp 升级到 3.12.12 ,不需要兼容的话直接升级到 4.9.0 吧。
haydenjie
    2

haydenjie   92 天前

我看了一下这个 allowaccessmodification 这个配置工程里面没有,但是在 build 里面生成的配置文件里面找了这个,这个配置好像只会把 private 变成 public 。 现在是 bugly 上统计到部分 Android11 的手机出现,我找相同的手机却不能出现这个报错。

云原生:云计算时代命题之终*解决方案

云原生这个词其实由来已久,IT行业永远也不缺乏新概念。2015 年,Pivotal公司的Matt Stine提出Cloud Native这一概念,并结合这个概念包装了自己的新产品Pivotal Web Service和Spring Cloud。在Matt Stine所著的Migrating to Cloud Native Application Architectures一书中,他对云原生的概念进行了详细的阐述。该书的中文版《迁移到云原生应用架构》已经在GitHub 上开源,感兴趣的读者可浏览或下载。

什么是云原生
云原生准确来说是一种文化,更是一种潮流,它是云计算的一个必然导向。意义在于让云成为云化战略成功的基石,而不是障碍。
自从云的概念开始普及,许多公司都部署了实施云化的策略,纷纷搭建起云平台,希望完成传统应用到云端的迁移。但是这个过程中会遇到一些技术难题,上云以后,效率并没有变得奇高,故障也没有迅速定位。
为了解决传统应用升级缓慢、架构臃肿、不能快速迭代、故障不能快速定位、问题无法快速解决等问题,云原生这一概念横空出世。云原生可以改进应用开发的效率,改变企业的组织结构,甚至会在文化层面上直接影响一个公司的决策。
另外,云原生也很好地解释了云上运行的应用应该具备什么样的架构特性——敏捷性、可扩展性、故障可恢复性。
综上所述,云原生应用应该具备以下几个关键词:

敏捷
可靠
高弹性
易扩展
故障隔离保护
不中断业务持续更新
以上特性也是云原生区别于传统云应用的优势特点。
从宏观概念上讲,云原生是不同思想的集合,集目前各种热门技术之大成,具体包括如下图所示的几个部分。
%title插图%num

微服务

  • 应用间通过RESTful API进行通信
  • 可以被独立的部署、更新、scale和重启

并不是所有的应用都适合微服务化,也不是说将一个单体应用拆分的越细越好。谈到微服务就不得不提到”十二因素法则“,如下图所示。

%title插图%num

DevOps
自动化发布管道、CI工具
快速部署到生产环境
开发、运维协同合作
设计系统的组织,*终产生的设计等同于组织之内、之间的沟通结构。
——康威定律
开发和运维看似是两个貌似互相矛盾的角色。因为开发负责业务的持续迭代,会为系统引入大量的变更,如果系统正在稳定运行,那么每次上线和发布都给系统带来新的风险。而运维追求的是系统可用性、SLA、而变更就意味着可能带来的不稳定。

持续交付
频繁发布、快速交付、快速反馈、降低发布风险
构建自己的CI/CD 持续构建管道与发布流程,如使用Jenkins。

容器化
微服务的*佳载体
容器化*大的好处是保持运行环境的一致性,只要应用可以打包成容器镜像(我们通常使用Docker容器),就可以一次编译,然后到处运行。
同时,容器也可以作为应用运行的*小组件来部署,且更适合作为无状态应用的运行。结合容器编排工具(如Kubernetes)将大大增强系统的扩展性和自愈能力,轻松应对大流量下的高并发场景,加快业务的迭代速度,Kubernetes作为CNCF成员的核心,本身就是与云原生应用的理念紧密结合的产物。
云原生中包含的不同思想,与其所解释的云上应用架构应该具备的特性几乎是一一对应的。

DevOps、持续交付对应更快的上线速度,即敏捷性。
微服务对应可扩展性及故障可恢复性。
敏捷基础设施实现了扩展能力的资源层支持。
康威定律在组织机构和流程上确保架构特性能够快速实施。
后记
云时代的云原生应用大势已来,将传统的单体架构应用迁移到云原生架构上,你准备好了吗?
俗话说,意识决定行动。在迁移到云原生应用之前,我们需要先对 Cloud Native(云原生)的概念、组织形式、实现技术有一个大概的了解,这样才能真正进入到云原生架构实践中。
公有云大行其道,私有云厂商也不断涌现,为了业务的快速迭代,为了快速形成自己的产业生态,各个业务需求方都在积*的评估和采纳公有云方案。
真正的云原生应用架构不应该限制应用的开发语言和架构选择,虽然目前以Java应用的开发者居多,在云原生概念出来之前就已经积累了不少分布式应用管理经验,如Netflix OSS。
实际上云原生应用架构应该适用于任何应用类型。云原生应用架构适用于异构语言的程序开发,不仅仅是针对Java语言。目前云原生应用生态系统已经初具规模,CNCF成员不断发展壮大,基于Cloud Native的创业公司不断涌现,Kubernetes引领容器编排潮流和 Service Mesh技术,Go语言的兴起等,这些都为将传统应用迁移到云原生架构提供了更多的选择。
————————————————

原文链接:https://blog.csdn.net/broadview2006/article/details/80131068

Lineage OS 下微信断流问题

断开 Wi-Fi 连接后,经常出现其他 APP 可以正常上网,微信不行的现象,向各位请教下解决方法。

已将微信的电源管理设置为不优化; APN 设置为 CMNET (移动);首选网络类型设置为 LTE Only 。

两部手机( Sony Xperia XZ2 、红米 K20 )都有这个问题,刷的都是官方 Lineage OS 17.1 。

21 条回复    2021-01-08 22:56:19 +08:00
systemcall
    1

systemcall   94 天前

要运行微信 OS,手机 ROM 里要放上相关的 SDK 。不然对微信 OS 支持不好
dexter
    2

dexter   94 天前

哪些 os 相关 sdk?
kokutou
    3

kokutou   94 天前

叹号去了吗?
PhaSelEza
    4

PhaSelEza   94 天前   ❤️ 1

@kokutou 是指 Captive Portal 吗?我都用这个命令关掉了。

adb shell settings put global captive_portal_mode 0

hydraegret
    5

hydraegret   94 天前   ❤️ 1

pixel 上的微信都会比 pc 延迟收到消息,约延迟 1-3 分钟。
Maboroshii
    6

Maboroshii   94 天前 via Android   ❤️ 1

关掉 volte 试试。 我的小米 8 类原生系统都有这个问题。WiFi 回到 4g 会出现 dns 请求发不出去的情况,关掉 volte 就好了
kokutou
    7

kokutou   94 天前 via Android   ❤️ 1

@PhaSelEza
打开换个可以正常使用的服务器
比如小米的
madpecker009
    8

madpecker009   94 天前 via Android

@hydraegret 小米 8 也延迟 不过没你的这么离谱 也就是在 3s 左右
YvanGu
    9

YvanGu   94 天前

华为 EMUI 上微信也延迟,3-5 分钟,电脑端登陆的情况下。
HankAviator
    10

HankAviator   94 天前 via Android   ❤️ 1

米 6 los17.1,未电池优化,play 版微信没有问题。
私人 dns 已关闭。
Lin0936
    11

Lin0936   94 天前

pixel3 上 play 版微信没发现延迟断流,甚至感觉比 iOS 推送还快一点
alfchin
    12

alfchin   94 天前 via iPhone

@YvanGu 那是功能吧。。。
treblex
    13

treblex   94 天前

请问这个 rom,键盘收起之后,下半屏无法点击的 bug 修复了吗
YvanGu
    14

YvanGu   94 天前

@alfchin 额。。。手机端晚于电脑端收到信息有什么有利的功能嘛?
PhaSelEza
    15

PhaSelEza   94 天前

感谢各位的答复。我开启了 Captive Portal (网址设置为谷歌中国),关闭了私人 DNS,关闭了 VOLTE 。现在似乎正常了,我再试用几天。
PhaSelEza
    16

PhaSelEza   94 天前

@suke971219 日常使用中没有遇到这个 bug,有什么可以复现的方法吗?
treblex
    17

treblex   94 天前

@PhaSelEza #16 开发 app 时候遇到的 可能需要做兼容吧,就是比较靠近底部的 input,点击输入再取消就会遇到
bclerdx
    18

bclerdx   94 天前 via Android

@PhaSelEza 你怎么关掉 CaptivePortal 的。
q197
    19

q197   94 天前

@bclerdx adb 执行他写的那段代码
bclerdx
    20

bclerdx   94 天前 via Android

@q197 明白。多谢。
bclerdx
    21

bclerdx   91 天前

@q197 那么 Google Android 原生系统从 5.0-11,Captive Portal 探测的是哪个具体网址或域名呢?

什么是云原生架构

云计算提供了对无限IT资源的按需付费的商业模式,但从技术架构上看,还需要一个用于构建和运行云原生应用的平台,来实践敏捷开发、DevOps、容器编排,微服务和容器化等理论和方法。

 

云原生平台
敏捷开发
一种小规模团队的、全栈式的开发方法,要求团队具备快速响应变化,快速迭代开发的能力。

*佳实践

scrum
xp
DevOps
开发和运维之间保持流程连续的协作方法,目标是快速、频繁且更可靠地构建、测试和发布软件。

*佳实践

Jenkins
GitLab
容器编排
一种容器资源的管理方法,目标是管理容器集群和调度容器化应用。

*佳实践

Kubernetes
Docker Swarm
Mesos
云原生应用
微服务
是将大型应用作为小型服务集合进行开发的架构方法,其中每个服务都可实现业务功能,在自己的流程中运行并通过 HTTP API 进行通信。每个微服务都可以独立于其它服务进行部署、升级、扩展和重新启动,通常作为自动化系统的一部分运行,可以在不影响*终客户的情况下频繁更新正在使用中的应用。

*佳实践

Spring Boot
Spring Cloud
Jhipster
容器化
与虚拟机相比,容器能同时提供更好的效率和启动速度。每个容器都具有唯一的可写文件系统和资源配额。创建和删除容器的开销较低,在单个虚拟机上能通过容器化充分利用物力资源,这使的容器成为部署微服务的完美工具。

*佳实践

Docker Image
OCI
云原生应用与传统应用

%title插图%num