精华内容
下载资源
问答
  • Linux原生软件推荐

    千次阅读 2019-02-20 22:19:13
    Linux原生软件推荐1. 概述2. 日常使用2.1 浏览器---chromium2.2 浏览器---Firefox2.3 记事本---gedit2.4 音乐---网易云音乐2.5 远程协助---TeamView2.6 远程登录---Remmina2.7 系统清理---BleachBit2.8 系统备份---...

    1. 概述

    个人使用过,感觉还不错的,在此记录持续更新

    2. 日常使用

    2.1 浏览器—chromium

    跨平台,体验与Windows一致

    2.2 浏览器—Firefox

    跨平台,体验与Windows一致

    2.3 记事本—gedit

    2.4 音乐—网易云音乐

    跨平台,体验与Windows一致

    2.5 远程协助—TeamView

    跨平台,体验与Windows一致

    2.6 远程登录—Remmina

    2.7 系统清理—BleachBit

    2.8 系统备份—Systemback

    2.9 邮件—Thunderbird

    跨平台,体验与Windows一致

    2.10 pdf阅读器—foxit Reader

    跨平台,体验与Windows一致

    2.11 办公文档—WPS

    跨平台,体验与Windows一致(相较于Windows界面更清爽,无广告)

    2.12 chm文档浏览器—ChmSee

    类似于Windows上帮助文件查看器

    2.13 通讯—Electronic WeChat(微信)

    微信网页版

    2.14 截图—Deepin Scrot(深度截图)

    类似于Windows上QQ截图功能

    2.15 录屏—Peek

    2.16 软件包安装—GDebi

    2.17 文件管理器—Caja

    另外单独使用如下命令:安装caja-gtkhash扩展可以比较方便的校验文件,推荐

    sudo apt install caja-gtkhash
    

    2.18 视频—VLC

    2.19 VPN登录—EasyConnect

    跨平台,体验与Windows一致

    2.20 游戏—steam

    跨平台,体验与Windows一致

    2.21 游戏—xAPPCenter

    安卓模拟,个人感觉主要作用是可以玩安卓游戏,比如炉石传说、王者荣耀等

    2.22 游戏—VisualBoy Advance

    2.23 游戏—Fceux

    2.24 游戏—DGEN

    3.编程开发工具

    3.1 编辑器—Vim(GVim)

    3.2 编辑器—VSCode

    跨平台,体验与Windows一致

    3.3 虚拟机—VirtualBox

    跨平台,体验与Windows一致

    3.4 IDE—Qt Creator

    跨平台,体验与Windows一致

    3.5 工具—JetBrains Toolbox

    跨平台,体验与Windows一致

    JetBrains系列软件安装器,可以安装JetBrains全家桶

    3.6 IDE—Android Studio

    跨平台,体验与Windows一致

    3.7 IDE—IntelliJ IDEA

    跨平台,体验与Windows一致

    3.8 IDE—PyCharm

    跨平台,体验与Windows一致

    3.9 Markdown编辑器—Typora

    跨平台,体验与Windows一致

    3.10 对比工具—beyond Compare

    收费软件,可以使用Meld代替

    跨平台,体验与Windows一致

    3.11 16进制编辑器—wxHexEditor

    类似于Windows的winhex

    3.12 反汇编调试工具—edb

    类似于Windows的olldbg

    3.13 网络抓包工具—Wireshark

    跨平台,体验与Windows一致

    3.14 串口工具—SecureCRT

    跨平台,体验与Windows一致

    收费软件,可以使用putty代替

    3.15 嵌入式开发工具—SystemView

    跨平台,体验与Windows一致

    3.16 嵌入开发工具—STM32CubeMX

    跨平台,体验与Windows一致

    3.17 嵌入式开发工具—DSView

    跨平台,体验与Windows一致

    3.18 git图形化工具—GitKarken

    跨平台,体验与Windows一致(6.5.0版本之后开始收费,建议安装6.5.0版本以及之前的版本)

    3.19 api查询手册—Zeal

    跨平台,体验与Windows一致

    3.20 ftp图形化工具—FileZilla

    3.21 MQTT图形化工具—MQTTfx

    3.22 软键盘工具—florence

    展开全文
  • 第二篇 - 云原生软件架构(本文) 第三篇 - 云原生应用交付与运维体系(待续) 前言 在《云原生基础设施》一文中我们谈到了,云原生计算包含三个维度的内容,云原生基础设施,软件架构和交付与运维体系,本文将...

    作者 | 易立,阿里云资深技术专家,容器技术负责人

    本系列文章:
    第一篇 - 云原生基础设施 (已发布,文末点击阅读原文查看)
    第二篇 - 云原生软件架构(本文)
    第三篇 - 云原生应用交付与运维体系(待续)

    前言

    在《云原生基础设施》一文中我们谈到了,云原生计算包含三个维度的内容,云原生基础设施,软件架构和交付与运维体系,本文将聚焦于软件架构层面。

    “Software architecture refers to the fundamental structures of a software system and the discipline of creating such structures and systems. ” - 维基百科。

    在我的理解,软件架构主要目标是解决下列挑战:

    1、控制复杂性。由于业务的复杂性,需要我们用更好的手段帮助研发组织克服认知障碍,更好的分工协作。分而治之,关注点分离等手段皆是如此。

    2、应对不确定性。业务在快速发展,需求在不断变化。即使再完美的软件架构,然而随着时间的推移,团队的变化,软件架构的调整不可避免。读《设计模式》,《微服务设计》等书字里行间写的都是“解耦”两字,让我们关注架构中确定性和不确定性的分离,提升架构的稳定性和应变能力。

    3、管理系统性风险。管理系统中的确定性以及不确定性风险,规避已知陷阱,对未知的风险做好准备。

    云原生应用架构的目标是构建松耦合、具备弹性、韧性的分布式应用软件架构,可以更好地应对业务需求的变化和发展,保障系统稳定性。本文将分享我在这个领域的观察和思考。

    缘起 - 12要素应用

    2012 年,Heroku 创始人 Adam Wiggins 发布十二要素应用宣言。它为构建一个优雅的互联网应用,定义了需要遵循的一些基本原则和方法论,也广泛影响了众多的微服务应用架构。十二要素重点关注:应用程序的健康成长,开发者之间的有效的协作,以及避免软件架构腐化的影响。其内容在今天也值得每个同学认真体会。

    image.png
    图片来源:https://12factor.net/zh_cn/

    12 要素应用为我们提供了很好的架构指导,帮助我们:

    1、构建水平伸缩的弹性应用架构,更好支撑互联网规模应用。
    2、提升研发流程的标准化、自动化水平,提升研发效率。

    3、减少开发环境和生产环境的差异,并使用持续交付实施敏捷开发。
    4、提升应用的可移植性,适合云化部署,降低资源成本和管理复杂性。

    松耦合架构设计

    微服务的核心理念是,系统中的各个服务可被独立开发、独立部署,独立升级,各个服务之间是松耦合的。云原生应用架构理念是进一步强调架构的松耦合,降低服务之间相互依赖的程度。

    API 优先的应用架构设计

    在面向对象的软件架构中,最重要的是定义对象以及对象的接口契约。SOLID 原则是最被人广为熟知的设计原则。

    Single responsibility principle - 单一职责原则

    Open/closed principle - 开放/封闭原则
    Liskov substitution principle - 里氏替换原则
    Interface segregation principle - 接口隔离原则
    Dependency inversion principle - 依赖翻转原则

    将以上五个原则的英文首字母拼在一起就是 SOLID 原则,这也是帮助我们构建高内聚,低耦合、具备柔性的应用架构。在分布式微服务应用架构中,API优先是契约优先(Contract First)的自然拓展。

    API 应该是被优先设计的:我们知道用户需求是复杂多变的,比如从桌面到移动端,应用的展现方式和操作流程都有可能不同;然而业务逻辑的概念模型和服务交互是相对稳定的。相对而言,API 的接口是更加稳定的,而具体的实现是可以迭代实现和持续变化的。定义良好的 API 可以更好保障应用系统的质量。

    API 应该是声明式,可描述/自描述的:通过规范化的描述,API 易于沟通、易于理解、易于验证,简化开发协同。支持服务的消费者和提供者并行开发,加速开发周期。支持不同的技术栈的实现,比如对于同一个 API 接口,其服务实现采用 Java 。前端应用可以使用 JavaScript ,而服务器端应用可以使用 Golang 进行服务调用等等。这样可以让开发组织可以根据自己的技能栈和系统要求灵活选择合适的技术。

    API 应该具备 SLA :API 作为服务间的集成界面,与系统的稳定性息息相关。SLA 应该作为 API 设计的一部分,而不是部署后再考虑。在分布式系统中,稳定性风险无处不在,通过 API 优先的设计模式,我们对独立的服务进行稳定性架构设计、容量规划;我们还可以对独立的 API 进行故障注入、稳定性演练,来消除系统性的稳定性风险。

    在 API 领域,最重要的趋势是标准化技术的崛起。gRPC 是 Google 开源的的高性能、通用的、平台无关的 RPC 框架。它采用分层设计,其数据交换格式基于 Protobuf (Protocol Buffers) 协议开发,具备优秀的序列化/反序列化效率,也支持众多开发语言。在传输层协议, gRPC 选择了 HTTP/2,相较于 HTTP/1.1,其传输效率有了很大提升。此外 HTTP/2 作为一个成熟的开放标准,具备丰富的安全、流控等能力,同时拥有良好的互操作性。gRPC 不仅可以用于 Server 端服务调用,也可以支持浏览器、移动 App 和 IoT 设备与后端服务的交互。gRPC 在功能上已经具备完整的 RPC 能力,也提供了扩展机制来支持新的功能。

    在 Cloud Native 的潮流下,跨平台、跨厂商、跨环境的系统间互操作性的需求必然会催生基于开放标准的 RPC 技术,而 gRPC 顺应了历史趋势,得到了越来越广泛地应用。在微服务领域, Dubbo 3.0 宣布了对 gRPC 协议的支持,未来我们也会看到更多的微服务架构基于 gRPC 协议开发,并提供良好的多语言支持。此外,在数据服务领域,gPRC 也成为一个优秀的选择,大家可以参考 Alluxio的文章:
    https://www.alluxio.io/blog/moving-from-apache-thrift-to-grpc-a-perspective-from-alluxio/

    此外在 API 领域 Swagger (OpenAPI规范),GraphQL 都是大家值得关注的开放标准。大家根据自己的业务诉求灵活选用,本文不再赘述。

    Event Driven Architecture 的崛起

    谈事件驱动架构 (EDA - Event Driven Architecture),我们首先来解释一下什么是事件。事件是指对已经发生的事情、状态变化等的记录。它们是不可变的(无法更改或删除),并且按其创建顺序排序。相关各方可以通过订阅已发布的事件来获取有关这些状态变化的通知,然后使用所选择的业务逻辑根据这些信息采取操作。

    事件驱动架构是一种构建松耦合的微服务系统的架构方式,微服务之间通过异步事件通信来进行交互。

    事件驱动架构实现了事件的生产者和消费者的彻底解耦。生产者无需关注事件如何被消费,同时消费者无需关注事件的生产方式;我们可以动态添加更多消费者而不影响生产者,可以增加消息中间件对事件进行动态路由和转换。这还意味着事件的生产者和消费者没有时序上的依赖,即使由于应用宕机无法及时处理消息,在重新恢复后,程序可以继续从消息队列中获取这些事件继续执行。这样的松耦合架构,为软件架构提供更高的敏捷性、灵活性和健壮性。

    事件驱动架构的另一个重要优点是提升了系统的可伸缩性。事件生产者在等待事件消费时不会被阻塞,并且可以采用 Pub/Sub 方式,让多个消费者并行处理事件。

    事件驱动架构还可以完美地与 Function as a Service (FaaS) 相整合。事件触发函数执行业务逻辑,在函数中也可以编写集成多个服务的“胶水代码”,简单、高效地构建事件驱动架构的应用。

    但是 EDA 架构依然存在很多挑战。

    1、分布式的松耦合架构大大增加了应用基础设施的复杂性。基于云的部署交付方式和云服务(消息队列、函数计算服务等)可以使得该架构的稳定性,性能和成本效益进一步提高。

    2、与传统同步处理方式相比,异步事件处理存在与事件排序、幂等性、回调和异常处理相关的要求,整体设计难度更大一些。

    3、在大多数情况下,由于缺乏跨多个系统的分布式事务支持,维护数据一致性是非常具有挑战性的。开发者可能需要权衡可用性和一致性之间的关系。比如通过Event Sourcing(事件溯源)实现最终一致性,详情:
    https://martinfowler.com/eaaDev/EventSourcing.html

    4、互操作性。在现实世界中,事件无处不在,然而不同生产者对事件的描述却不尽相同。开发者希望无论事件是从哪里发出,都能够以一致的方式构建事件驱动的应用程序。CloudEvents(https://cloudevents.io/) 是一种以通用、一致的方式描述事件数据的规范,由 CNCF Severless 工作组提出,提升了事件驱动应用的可移植性。目前,阿里云 EventBridge、Azure Event Grid 等事件处理中间件,以及 Knative Eventing ,阿里云函数计算等 FaaS 技术已经提供了对 CloudEnvents 的支持。

    由于 EDA 自身架构的优点,在互联网应用架构,业务数据化和智能化、IoT等场景有非常广阔的前景。关于 EDA 的架构讨论,不在此继续展开。

    面向交付的应用架构

    在云原生软件架构中,我们在设计阶段不只是关注软件如何被构建,也需要以终为始。关注如何合理设计和实现软件,才可以被更好地交付和运维。

    应用和运行环境解耦

    在 12 要素应用中,应用和运行环境解耦就已经被提出。而 Docker 容器的出现则进一步加强了这个理念。容器是一种轻量化的应用虚拟化技术,容器之间共享操作系统内核,支持秒级启动,Docker 容器镜像是一个自包含的应用打包格式,将应用和其依赖(如系统库、配置文件)等打包在一起,在不同环境保持部署一致性。

    容器可以作为 Immutable Infrastructure (不可变基础设施)的基础,提升应用交付的稳定性。不可变基础设施是由 Chad Fowler 于 2013 年提出的构想:在这种模式中,任何基础设施的实例(包括服务器、容器等各种软硬件)一旦创建之后便成为一种只读状态,不可对其进行任何更改。如果需要修改或升级某些实例,就是创建一批新的实例进行替换。这种模式的可以减少了配置管理工作的负担,保障系统配置变更和升级可以可靠地重复执行,避免令人头疼的配置漂移问题;易于解决部署环境间的差异,让持续集成与持续部署过程变得更流畅;支持更好的版本管理,在部署出错时可进行快速回滚,

    image.png
    Kubernetes 作为容器的分布式编排调度系统,进一步提升了容器应用的可移植性。K8s通过一系列抽象如 Loadbalance Service, Ingress, CNI, CSI,帮助业务应用可以屏蔽底层基础设施的实现差异,灵活迁移。通过这样的能力,我们可以实现工作负载在数据中心、边缘计算和云环境的动态迁移。

    在应用架构中,我们需要避免将静态环境信息,比如IP,mac地址等与应用逻辑耦合。在微服务架构中,可以利用 Zookeeper/Nacos 等实现服务的注册发现;在 Kubernetes 中,我们可以通过 Service,Service Mesh 减少对服务端点IP的依赖。此外,对应用状态的持久化也尽可能通过分布式存储或者云服务等实现,这样可以大大提升应用架构可伸缩性和自愈能力。

    自包含可观测性

    分布式系统所面对的最大挑战之一就是可观测性。可观测性可以帮助我们解系统当前的状态,并作为应用自愈,弹性伸缩和智能运维的基础。

    在云原生架构中,微服务应用是自包含的,应该自己具备可观测性,可以方便地被系统进行管理和探查。首先是,应用应该具备自身健康状态的可视化能力。

    在 Kubernetes 中,业务应用可以提供一个 liveness 探针,可以通过 TCP、HTTP 或者命令行方式对应用就绪进行检测。对于 HTTP 类型探针,Kubernetes 会定时访问该地址,如果该地址的返回码不在 200 到 400 之间,则认为该容器不健康,会杀死该容器重建新的容器;

    image.png
    对于启动缓慢的应用,为了避免在应用启动完成之前将流量导入。Kubernetes 支持业务容器提供一个 readiness 探针,对于 HTTP 类型探针,Kubernetes 会时访问该地址,如果该地址的返回码不在 200 到 400 之间,则认为该容器无法对外提供服务,不会把请求调度到该容器;
    image.png
    同时在新的微服务架构中已经内置了可观测探针,比如在 SpringBoot 的 2.3 发布了两个新的 actuator 地址,/actuator/health/liveness 和 /actuator/health/readiness ,前者用作存活探针,后者用作就绪探针。业务应用可以通过Spring系统事件机制来读取、订阅、修改 Liveness State 和 Readiness State ,这样可以让 Kubernetes 平台可以做更加准确的自愈和流量管理。

    更多信息可以参考 :
    https://spring.io/blog/2020/03/25/liveness-and-readiness-probes-with-spring-boot

    此外,应用可观测性包含三个关键能力:日志、监控与链路追踪。
    image.png
    1、Logging – 日志(事件流):用于记录离散的事件,包含程序执行到某一点或某一阶段的详细信息。不但包括应用、 OS 执行过程的日志,还应包含运维过程中的日志信息,如操作审计等。

    2、Metrics – 监控指标:通常是固定类型的时序数据,包括 Counter、Gauge、Histogram 等,是可聚合的数据。系统的监控能力是多层次的,既包含计算、存储,网络等基础设施服务层次的监控指标,也应该包含业务应用的性能监控和业务指标监控。

    3、Tracing – 链路追踪 - 记录单个请求的完整处理流程,可以为分布式应用的开发者提供了完整的调用链路还原、调用请求量统计、应用依赖分析等能力,能够帮助开发者快速分析和诊断分布式应用架构下的性能和稳定性瓶颈。

    在分布式系统中,稳定性、性能、安全等问题可能发生在任何地方,需要全链路可观测性能力保障,需要覆盖基础设施层、 PaaS 层,应用等不同层次,并且可以在不同系统间实现可观测性数据的关联、聚合、查询和分析。

    软件架构的可观测领域具备广阔的前景,也涌现出众多的技术创新。2020 年 9 月 CNCF 发布了云原生可观测性的技术雷达:
    https://www.cncf.io/blog/2020/09/11/cncf-end-user-technology-radar-observability-september-2020/
    image.png

    其中,Prometheus 已成为企业首选的云原生应用程序的开源监控工具之一。Prometheus 培养了一个活跃的开发者和用户社区。在 Spring Boot 应用架构中,通过引入 micrometer-registry-prometheus 的依赖,既可以让应用的监控指标被 Prometheus 服务所采集。更多信息可以参考文档:
    https://docs.spring.io/spring-boot/docs/current/reference/html/production-ready-features.html

    在分布式追踪领域,OpenTracing 是 CNCF 下属的开源项目。它是一个技术中立的分布式追踪的规范,提供统一接口,可方便开发者在自己的服务中集成一种或多种分布式追踪的实现。Jaeger 是Uber 开源的分布式追踪系统,兼容 OpenTracing 标准,已经成功在 CNCF 毕业。此外OpenTelemetry是一个潜在的标准,它试图在融合 OpenTracing 和 OpenCensus 这两个项目,形成统一的技术标准。

    对于很多遗留的业务系统,现有应用并不具备完备的可观测性能力。新兴的服务网格技术可以成为提升系统可观测性的新方式。通过数据平面代理的请求拦截,网格可以获取服务间调用的性能指标。此外,在服务调用方应用中只需加入需要转发的消息 header,在服务网格上即可获得完整的链路追踪信息。这样的方式极大简化了可观测性能力的建设,可以让现有的应用低成本融入云原生可观测性体系中。

    阿里云提供了丰富的可观测性能力。XTrace分布式追踪提供了对 OpenTracing/OpenTelemetry 标准的支持。ARMS 提供了托管 Prometheus 服务,可以让开发者无需关注系统的高可用和容量挑战。可观测性是 AIOps 的基础,在未来企业IT应用架构中将扮演更加重要的角色。

    面向失败的设计 - Design For Failure

    根据”墨菲定律“ — “Anything that can go wrong will go wrong”。分布式系统可能受到硬件、软件等因素、或者内部和外部的人为破坏。云计算比自建数据中心提供了更高SLA、更加安全的基础设施,但是我们在应用架构设计时依然要时刻关注系统的可用性,关注潜在的”黑天鹅“风险。

    系统化的稳定性需要在软件架构,运维体系和组织保障等方面全局考虑。在架构层面,阿里经济体有着非常丰富的经验,比如防御式设计、限流、降级、故障隔离等,而且也向社区贡献了Sentinel、ChaosBlade等优秀的开源项目。

    本文,我会谈谈几个在云原生时代可以进一步思考的地方。我的总结是 “Failures can and will happen, anytime, anywhere. Fail fast, fail small, fail often and recover quickly.”

    首先是“Failures can and will happen”,我们需要提升服务器的可替换性。在业界有一个非常流行的隐喻:“Pets vs. Cattle”,宠物和家畜。我们面对一个架构选择:对于应用所在服务器我们是需要精心伺候,防止系统宕机,出现问题后不惜一切代价抢救 (Pet);还是倾向于出现问题后,可以通过简单抛弃和替代进行恢复(Cattle)。云原生架构的建议是:允许失败发生,确保每个服务器,每个组件都能够在不影响系统的情况下发生故障并且具备自愈和可替代能力。这个设计原则的基础是应用配置和持久化状态与具体运行环境的解耦。Kubernetes 的自动化运维体系让服务器的可替换性变得更加简单。

    此外是 “Fail fast, fail small, recover quickly” 。立即失效(Fail fast)是一个非常反直觉的设计原则,它背后的哲学是既然故障无法避免,问题越及早暴露、应用越容易恢复,进入生产环境的问题就越少。采用了 Fail-fast 策略以后,我们的关注点将从如何穷尽系统中的问题转移到如何快速地发现和优雅处理失败。只要跑的够快,故障就追不上我。:-) 在研发流程上,通过集成测试尽可能在早期发现应用存在的问题。在应用级别,可以采用断路器(Circuit Breaker)等模式防止一个依赖服务的局部故障引起全局问题;此外通过 K8s 的健康监测、可观测性可以实现对应用故障的探知,通过服务网格的断路器功能,可以将故障发现、流量切换和快速自愈这些能力外置到应用实现之外,由系统能力保障。Fail small的本质在于控制故障的影响范围——爆炸半径。这个原则在架构设计和服务设计上都需要我们持续关注。

    最后是“Fail often”,混沌工程是一种在生产环境周期性引入故障变量,验证系统对非预期故障防御的有效性的思想。Netflix 引入混沌工程概念解决微服务架构的稳定性挑战,也得到了众多互联网公司的广泛应用。在云原生时代又有了更多新的手段,Kubernetes 让我们可以轻松注入故障,杀死pod,模拟应用失效和自愈过程。利用服务网格我们可以对服务间流量进行更加复杂的故障注入,比如 Istio 可以模拟缓慢响应、服务调用失败等故障场景,帮助我们验证服务间的耦合性,提升系统的稳定性。

    更多关于交付和运维架构的更多稳定性思考,我们会在下一篇文章中和大家分享。

    应用基础设施能力下沉

    云原生软件架构的重要目标让开发者关注业务逻辑,让平台去承载系统复杂性。云原生计算重新定义了应用与应用基础设施的边界,进一步提升了开发效率,降低了分布式应用开发的复杂性。

    服务治理能力与业务逻辑解耦

    在微服务时代,以 Spring Cloud 与 Apache Dubbo 为代表的应用框架取得了巨大的成功,它们通过代码库方式提供了服务通信、服务发现和服务治理能力(流量转移、熔断、限流、全链路追踪等)。这些代码库被构建在应用程序本身中,随着应用一起发布和维护。这样的架构存在一些无法回避的挑战。

    1、侵入性:服务治理本质是横向的系统级关注,是与业务逻辑正交的。但在现有微服务框架中,其实现方式和生命周期与业务逻辑耦合在一起的。服务治理能力的增强需要微服务框架的升级,会导致整个系统所有组件的重新构建和部署,导致升级和维护成本提升。

    2、实现绑定:由于微服务框架代码库通常由特定语言实现,难以支持多语言(polyglot)实现。随着业务的快速发展,异构系统之间的集成逐渐成为挑战。

    image.png
    https://philcalcado.com/2017/08/03/pattern_service_mesh.html

    为了解决上述挑战,社区提出了 Service Mesh(服务网格)架构。它将业务逻辑与服务治理能力解耦。下沉到基础设施,在服务的消费者和提供者两侧以独立进程的方式部署。这样既达到了去中心化的目的,保障了系统的可伸缩性;也实现了服务治理和业务逻辑的解耦,二者可以独立演进不相互干扰,提升了整体架构演进的灵活性;同时服务网格架构减少了对业务逻辑的侵入性,降低了多语言支持的复杂性。

    Google、IBM、Lyft 主导发起的 Istio 项目就是服务网格架构的一个典型的实现,也成为了新的现象级“网红”项目。
    image.png

    上图是Istio的架构,逻辑上分为数据平面和控制平面。数据平面负责服务之间的数据通信。应用和以 sidecar 方式部署的智能代理 Envoy 成对出现。其中由 Envoy 负责截获和转发应用网络流量,收集遥测数据并且执行服务治理策略。在最新的架构中, istiod 作为控制平面中负责配置的管理、下发、证书管理等。Istio 提供了一系列通用服务治理能力,比如:服务发现和负载均衡,渐进式交付(灰度发布),混沌注入与分析,全链路追踪,零信任网络安全等。可以供上层业务系统将其编排到自己的IT架构和发布系统之中。

    服务网格在架构上实现了数据平面与控制平面的分离,这是一个非常优雅的架构选择。企业客户对数据平面有着多样化的需求,比如支持等多样化协议(如Dubbo),需要定制化的安全策略和可观测性接入等。服务控制平面的能力也是快速变化的,比如从基础的服务治理,到可观测性,到安全体系,稳定性保障等等。但是控制平面与数据平面之间的API是相对稳定的。

    CNCF 建立了通用数据平面 API 工作组(Universal Data Plane API Working Group / UDPA-WG),以制定数据平面的标准 API。通用数据平面 API(UDPA)的目标是:为 L4/L7 数据平面配置提供实现无关的标准化 API,类似于 OpenFlow 在 SDN 中对 L2/L3/L4 所扮演的角色。UDPA API 涵盖服务发现、负载均衡、路由发现、监听器配置、安全发现、负载报告、运行状况检查委托等。

    UDPA API 基于现有的 Envoy xDS API 逐步演进,目前除支持 Envoy 之外,将支持客户端负载均衡实现 (比如 gRPC-LB),更多数据平面代理,硬件负载均衡和移动客户端等等。

    我们知道 Service Mesh 不是银弹,其架构选择是通过增加一个服务代理来换取架构的灵活性和系统的可演化性,但是也增加了部署复杂性(sidecar管理)和性能损失(增加两跳)。UDPA 的标准化和发展将给服务网格架构带来的新一次变化。

    gRPC 在最新版本中提供了对UDPA负载均衡的初步支持:
    https://github.com/grpc/proposal/blob/master/A27-xds-global-load-balancing.md
    ”proxyless “服务网格概念浮出水面,一个概念示意图如下:
    image.png

    gRPC 应用直接从控制平面获取服务治理的策略, gPRC 应用之间直接通信无需额外代理。这个可以看到开放的服务网格技术的雄心,进化成为一套跨语言的服务治理框架,可以兼顾标准化、灵活性与运行效率。Google 的托管服务网格产品已经率先提供了对 ”proxyless“ gRPC 应用的支持。

    新一代分布式应用运行时

    对于分布式应用,Bilgin Ibryam 在Multi-Runtime Microservices Architecture :
    https://www.infoq.com/articles/multi-runtime-microservice-architecture/,文中分析并总结了典型的四大类需求:

    生命周期(Lifecycle)

    网络(Networking)
    状态(State)
    捆绑(Binding)
    image.png
    熟悉传统企业架构的同学可能发现,传统的 Java EE (现在改名为 Jakarta EE )应用服务器的目标也是解决类似的问题。一个典型 Java EE 应用服务器的架构如下图所示:应用生命周期由各种应用容器管理,如 Web 容器,EJB 容器等。应用的安全管理、事务管理、连接池管理都是交给应用服务器完成。应用可以通过 JDBC 、JMS 等标准 API 接口访问外部的企业中间件,如数据库、消息队列等。

    不同的外部中间件通过 Java Connector Architecture 规范实现与应用服务器的插拔。应用通过 JNDI 在运行时实现与具体资源的动态绑定。Java EE 将系统的 cross-cutting concern下沉到应用服务器来解决,让开发者只关注应用的业务逻辑,开发效率有了较好的提升;同时减轻应用对环境和中间件实现的依赖,比如可以在开发环境中用 ActiveMQ ,在生产环境中使用 IBM MQ 替换,而无需修改应用逻辑。

    image.png
    在架构上,Java EE 是一个大的单体应用平台,拖慢了自身架构迭代的速度,跟不上时代的变化。由于Java EE过于复杂、沉重,在微服务兴起之后已经被大多数开发者所遗忘。

    在云原生的时代,我们到底需要什么样的应用运行时?

    Dapr(https://dapr.io/)是微软给出的答案。Dapr 是一个事件驱动的,可移植的,构建微服务应用的运行时环境。支持应用在云或边缘部署,支持语言与框架的多样性。Dapr利用 Sidecar 的模式,把应用逻辑中的一些横切关注点需求(Cross-cutting)分离和抽象出来,从而达到应用与运行环境的解耦以及对外部依赖(包括服务之间)的解耦。

    image.png

    Dapr 的功能和定位如上图所示:

    1、最底下基础设施是各种云平台或者边缘环境。
    2、其上是 Dapr 运行时和“building block” (构件)。Dapr 构件解耦了外部服务和服务的消费者,可以按需加载。构件以统一的 HTTP/gPRC API 为应用层提供服务访问。我们可以将外部服务从 Amazon DyanamoDB 切换为 Azure ComosDB ,上层应用无需修改任何代码。Dapr 运行时作为一个独立的 sidecar 进程,独立于应用逻辑。
    3、应用通过轻量化的 SDK 来简化对构件 API 的调用,基于 gRPC/HTTP 开放协议可以轻松支持多语言。

    尽管 Dapr 和 Service Mesh 在架构上有些类似,服务治理功能有所重叠,但两者在本质上却大有不同。服务网格对应用是透明的基础设施;而 Dapr 为状态管理,服务调用和故障处理,资源绑定,发布/订阅,分布式跟踪等提供抽象,需要应用程序通过 SDK/HTTP/gRPC 显式调用 Dapr 能力,它是面向开发人员的开发框架。

    Dapr 还非常年轻,还在快速迭代中,距离被广大开发者和三方厂商所支持还有很长的路要走。但是 Dapr 给我们揭示出一个新的方向:通过关注点分离,让开发者只需关注业务逻辑自身,而分布式架构的系统关注下沉到基础设施中实现;让业务逻辑与外部服务解耦,避免厂商绑定;同时应用和应用运行时是两个独立的进程,通过标准化API进行交互,生命周期解耦,便于升级和迭代。

    Serverless 的机遇与挑战

    在上一篇文章中,我已经对 Serverless 应用基础设施,如函数即服务(FaaS), Serverless 容器做了介绍。本文谈谈函数即服务 FaaS 应用在架构方面的一些思考。

    FaaS 的核心思维是:开发者不必关心基础设施运维、容量规划或者扩容缩容,只需为使用的云资源和服务付费既可。这个思考的背后是:让开发者避免投入基础设施的运维,尽可能复用现有的云服务能力,让开发时间重新分配到对用户有更有直接影响和价值的事情上,比如健壮的业务逻辑、能吸引用户的界面及快速响应、可靠的 API 上。

    在软件架构层面中, FaaS 将复杂的业务逻辑拆解成一系列细粒度的函数,并通过事件驱动的方式触发调用。函数之间是松耦合的,可以通过如下两种典型的模式进行协同、组合。

    Workflow Orchestration 工作流编排:以阿里云 Serverless 工作流为例,可以通过一个声明式的业务流程来编排任务。这种方式简化了开发和运行业务流程所需要的任务协调、状态管理以及错误处理等繁琐工作,让开发者聚焦于业务逻辑开发。

    image.png
    Event Choreography 事件协调:函数服务之间通过事件交换消息,由事件总线等消息中间件来进行事件的转发,并触发其他函数执行。下面是一个示例应用场景,通过 EventBridge,将订单,用户通知、商家通知、接单、结单等基于函数实现的业务逻辑串联在一起。这种方式更加灵活,系统的健壮性也更好。但是缺点是缺乏显式的建模,开发和维护相对较复杂。
    image.png

    Serverless 具备很多优势, 比如:降低运维成本,提升系统安全性,提升研发效率,加速业务交付等等。然而 Serverless 还有一些不能回避的问题需要我们来做判断:

    成本管理: 对于“Pay as you go”的收费模式的一个弱点是无法准确预测具体会产生多少费用,这于许多组织预算管理的方式不同。

    厂商锁定: 即使 Serverless 应用基于开放的语言和框架,但是多数Serverless应用还依赖一些非标准化的 BaaS(Backend as a Service)服务,如对象储存,Key- Value 数据库,认证,日志,监控等。

    调试和监控: 与传统应用开发相比, Serverless 应用的调试与监控工具能力还不完善。良好的可观测性是将 serverless 计算的重要助力。

    架构复杂性:Serverless 开发者无需关注底层基础设施的复杂性,但是应用架构的复杂性需要格外关注。事件驱动架构和细粒度函数微服务,与传统开发模式非常不同。大家需要根据业务需求和自己的技术能力,在合适的场景应用,然后逐渐扩大应用范围。

    关于典型的 Serverless 应用架构,大家可以参考 What a typical 100% Serverless Architecture looks like in AWS ! :
    https://medium.com/serverless-transformation/what-a-typical-100-serverless-architecture-looks-like-in-aws-40f252cd0ecb

    Cloud Programming Simplified: A Berkeley View on Serverless Computing:
    https://www2.eecs.berkeley.edu/Pubs/TechRpts/2019/EECS-2019-3.pdf
    也是深入了解 Serverless 计算的一个好的参考。

    应用运行时的敏捷进化

    更快、更轻、更敏捷的应用运行时技术是云原生计算的持续追求。

    体积更小 - 对于微服务分布式架构而言,更小的体积意味着更少的下载带宽,更快的分发下载速度。

    启动速度更快 - 对于传统单体应用,启动速度与运行效率相比不是一个关键的指标。原因是,这些应用重启和发布频率相对较低。然而对于需要快速迭代、水平扩展的微服务应用而言,更快的的启动速度就意味着更高的交付效率,和更加快速的回滚,以及更快的故障恢复速度。

    占用资源更少 - 运行时更低的资源占用,意味着更高的部署密度和更低的计算成本。

    正因为此,Golang、Node.js、Python 等语言开发者在持续攀升,有几个值得大家关注的技术:

    在 Java 领域,GraalVM (https://www.graalvm.org/)已经逐渐成熟。它是基于HotSpot上增强的一个跨语言的全栈虚拟机,支持众多语言的运行平台(包括Java、Scala、Groovy、Kotlin、JavaScript、Ruby、Python、C、C++等)。GraalVM允许您将程序提前编译为本地可执行文件。

    与经典Java VM相比,生成的程序具有更快的启动时间和更低的运行时内存开销。Quarkus(https://quarkus.io/)/Micronaut(https://micronaut.io/) 等作为云原生定制的新一代Java框架,可以实现惊艳的启动时间和资源开销。更多分析可以参考Java的云原生进化。

    WebAssembly 则是另外一个令人激动的技术。WebAssembly 作为一个面向现代 CPU 体系架构设计的,安全的、可移植、高效率的虚拟机沙箱,可以在任何地方(服务器、浏览器、IoT等等)、任何平台(不同操作系统,不同CPU体系架构下)安全运行应用。WebAssembly System Interface(WASI)是来标准化 WebAssembly 应用与系统资源的交互抽象,比如文件系统访问,内存管理,网络连接等,提供类似 POSIX 这样的标准 API 。

    平台开发商可以针对具体的操作系统和运行环境提供 WASI 接口不同的实现,可以在不同设备和操作系统上运行跨平台的 WebAssembly 应用。这可以让应用执行与具体平台环境实现解耦,使得应用“Build Once, Run Anywhere”的理想逐渐形成现实。虽然目前 WebAssembly 已经超越了浏览器的领域,但是其发展还在非常初期,期待社区共同推动。有兴趣的同学可以看看 WebAssembly 与 Kubernetes 双剑合璧:
    https://www.infoq.cn/article/rEcOgQiurqaTyY7dJ6hA

    趋势总结

    image.png
    云原生软件架构还在快速发展中,涉及的内容也非常广泛。上述内容更多是个人总结、理解和判断,期待与大家的交流和深入探讨。

    更多参考:

    https://martinfowler.com/architecture/

    https://www.ibm.com/cloud/blog/7-missing-factors-from-12-factor-applications
    https://www.infoq.com/articles/microservices-design-ideals/
    https://www.infoq.com/articles/architecture-trends-2020/
    https://theburningmonk.com/2020/08/choreography-vs-orchestration-in-the-land-of-serverless/

    展开全文
  • 原生软件供应链安全演进.pptx
  • 原生软件供应链安全演进.pdf
  • 原生软件供应链安全演进架构.pptx
  • 原生软件供应链安全演进架构.pdf
  • 12月16-17日,由CNCF、网易数帆、VMware、PingCAP和阿里云联合主办2020 Cloud Native Day云原生生态大会线上召开,来自联合主办方及字节跳动、Zilliz、百胜中国等公司的17位重磅演讲嘉宾,带来2天主题分享,解析云...

    12月16-17日,由CNCF、网易数帆、VMware、PingCAP和阿里云联合主办2020 Cloud Native Day云原生生态大会线上召开,来自联合主办方及字节跳动、Zilliz、百胜中国等公司的17位重磅演讲嘉宾,带来2天主题分享,解析云原生领军企业和组织、头部用户的云原生战略与实践,剖析云原生技术带来的机遇与挑战,帮助云原生技术使用者和爱好者加深对技术的理解,同时推进云原生与企业IT的融合。

    在大会的第一天,网易数帆轻舟事业部总经理陈谔结合网易数帆旗下轻舟云原生平台近五年来的三次重大技术变迁,分享了网易及广大数字化进程中的企业在IT、业务架构上的需求演进背后的逻辑,软件生产与云原生之间的关系,以及网易数帆对未来的思考。

    陈谔将云原生软件生产分为三个阶段,包括业务架构微服务化阶段、云计算操作系统阶段和应用平台阶段,分别以服务治理与监控体系建立、中间件全面融合Kubernetes、应用视图与运维视图分离为重要特征。他断言,云原生的发展已经历了微服务阶段,当前处于云操作系统阶段,而应用平台阶段的发展也已经起步并将是未来的发展方向。

    云原生的起点:干掉微服务架构的复杂性

    微服务阶段技术演进的诉求发端于互联网/移动互联网的兴盛,明晰于微服务架构的复杂性。互联网时代,业务方需要在高度的业务复杂性下快速迭代软件。陈谔指出,分而治之是最符合直觉的解决办法,当时微服务架构也已被提出,也但拆分后的技术复杂性是不可忽略的因素,需要和迭代效率放在一起来权衡。 而云计算的出现首先解决了碎片化的计算资源获取问题,剩下的就基于云计算提供一个技术栈来应对微服务架构的复杂性。

    针对上述问题,网易数帆在实践的过程中逐渐形成了轻舟微服务平台,包括API 网关、服务治理框架、持续交付服务、全链路应用监控和分布式事务等五个组件。其中,持续交付平台负责调用云计算接口准备计算资源,并将制品发布至云上的各个环境;API网关解决分散的微服务架构作为一个整体应用对外提供接口的问题;服务治理解决服务的注册发现、以及服务间路由策略的问题;全链路监控解决微服务的监控诊断问题;分布式事务中间件解决了服务拆分后事务保障的难题。

    高潮:云OS基于K8s整治资源管理,简化环境维护

    微服务大规模应用的后遗症,就是计算资源的生命周期管理、运行时环境维护复杂以及资源利用率低下等。陈谔举了两个例子:一个是大促后弹性资源下线难,将一些节点下线,影响评估是否准确?服务的剩余副本数是否合理?服务是否能自动恢复到目标的副本数?另一个是调整集群调度分布困难,如希望将服务分布在不同的物理节点或逻辑上的服务分组,只能在静态初始化时做到,一旦后续发生变更就无法很好保障。

    容器、Kubernetes的出现使这些问题迎刃而解。容器镜像带来了层级化、易于组合/重用的优势,且管理便捷、可与调度、生命周期管理衔接;Kubernetes则带来了L1 CMDB,精准维护集群状态使调度策略变更、故障恢复、扩缩容等生命周期管理相关的操作得以实现自动化,同时还支持业务只需感知Kubernetes API而无需关注IaaS层API。基于此,网易数帆将业务、中间件等负载由Kubernetes支撑,并将微服务支撑能力下沉(即Service Mesh),形成一个云计算操作系统。

    陈谔分享了网易数帆云操作系统的三个案例,包括网易内部网易内部的资源利用率优化、高新制造业客户的多云管理以及企业的软件供应商环境统一等实践。(详情请关注后续视频回放。)

    云原生未来:应用平台助推软件生产能力普惠

    网易数帆在实践云OS的过程中也发现了新的问题和新的机遇。

    问题是开发人员的技术栈负担过重,微服务架构的采用使得中心化的运维职责部分(如容量规划以及调度策略、网络、存储配置等)卸载到了研发角色,而研发普遍不擅长处理这些工作,“然而我们认为软件生产能力的提升不应以技术门槛的提高为代价。”陈谔强调说。

    机遇在于统一的运维界面意味着将特定类型应用的运维标准化、自动化的可能性,从开发到运维转换,作为在软件生产过程中最具挑战的环节之一有望得到大幅的优化。

    作为云原生的底座Kubernetes一直没有应用层面的抽象,陈谔认为未来需要将应用的概念分离出来,来降低应用开发人员的认知负担。当前社区的OAM模型的尝试,也是网易数帆重点关注的一个方向。

    在以应用为中心的方向上,网易数帆希望基于云原生的普及实现软件生产能力普惠,让更多的人可以参与到应用开发中来,并拥有良好的开发效率。毕竟当前企业数字化的过程中,IT团队的交付能力经常成为瓶颈,一些有价值但不是非常核心的系统往往长期处于需求排队的状态。

    陈谔表示,软件生产能力的普惠主要是解决开发能力与运维能力这两方面的问题。开发能力方面通过缩小场景范围、弱化抽象能力、表达能力,提供所见即所得的编辑能力来降低开发人员的认知负担,这也是历史上低代码平台类产品常见的策略。

    运维能力方面,运维能力的缺失使非专业人员的代码产出无法融入企业的IT环境成为标准的企业服务,从而仅限于个人或小范围使用,而云原生的技术使我们可以为应用生成标准的运维配置、策略的描述,并且这些配置在云OS的统一运维界面下普遍适用。

    网易数帆的实践是打造了能与云原生体系结合的低代码平台,面向初级开发者,面向信息管理系统类的应用,基于MVVM的模型,但开发者无需理解编程语言的抽象、MVVM框架,网络,远程调用等概念,而只需理解业务的数据模型,编写必要的逻辑,并通过可视化的方式拖拽界面元素实现应用。

    陈谔介绍,该平台设计成能生成符合云原生标准的制品,如容器镜像与Helm charts,既能在轻舟的容器云中自动部署运行,也能在客户的Kubernetes集群中部署,简单应用可以直接通过容器部署。客户只要有面向K8s的运维机制,无需开发者提供额外信息即可基于制品部署运维,并能兼容客户运维体系的规范。

    客户需要更高级的能力时,也能以轻舟平台为云OS来扩展持续交付、自动部署、服务治理、API管理、中间件自动化运维等能力。

    Day2预告:网易数帆、百胜中国的云原生实践

    在大会的第二天,网易数帆将联合百胜中国分享网易集团及百胜中国的云原生相关技术实践与经验心得,敬请期待!

    议题:善于Service Mesh,网易云原生架构转型之路

    讲师:网易数帆轻舟事业部微服务平台负责人冯常健

    议题简介:云原生技术在企业IT转型过程中发挥越来越重要的作用,但摆在实践者面前的是如何用好云原生技术,发挥其应有的价值。本议题将分享主题网易自2016年开始探索的大规模Service Mesh技术应用与实践,以业务驱动技术架构升级,解析企业实施Service Mesh架构面临的问题、如何应对以及落地关键要素。

    议题:基于Kubernetes的微服务实践

    讲师:网易数帆轻舟事业部资深解决方案架构师王必成,百胜中国系统架构师申海龙

    议题简介:百胜中国作为中国餐饮领军企业,在中台建设过程中,基于餐饮行业的行业特性,结合主流的容器化技术、微服务化技术,打造多云环境,更低成本、高可用来支撑业务的持续发展之路。网易数帆轻舟事业部资深解决方案架构师王必成与百胜中国系统架构师申海龙将介绍百胜中国与网易共建的云原生基础设施体系,架构设计的深层思考,以及云原生在百胜中国业务应用的经验。

    B站直播:https://live.bilibili.com/22585337

    展开全文
  • Android 4.x原生软件详细列表

    千次阅读 2013-07-10 14:09:59
    谷歌读书软件(可删) BrowserGoogle.apk BrowserGoogle.apk  BrowserGoogle.apk 自带浏览器(可删,不过我觉得很好用) Calculator.apk Calculator.apk  Calculator....



    Andriod  4.0.4系统包 Andriod 4.1.1系统包 Andriod 4.2系统包 说明
    ApplicationsProvider.apk ApplicationsProvider.apk          ApplicationsProvider.apk 应用程序存储、 程序管理器(不可删)
    BackupRestoreConfirmation.apk BackupRestoreConfirmation.apk      BackupRestoreConfirmation.apk (不能删)
        BasicDreams.apk 4.2新增
    Bluetooth.apk Bluetooth.apk                     Bluetooth.apk 蓝牙(不能删)
    BooksTablet.apk Books.apk                         Books.apk 谷歌读书软件(可删)
    BrowserGoogle.apk BrowserGoogle.apk                BrowserGoogle.apk 自带浏览器(可删,不过我觉得很好用)
    Calculator.apk Calculator.apk                     Calculator.apk 计算器(可删)
    CalendarGoogle.apk CalendarGoogle.apk                CalendarGoogle.apk 日历(可删)
    CalendarProvider.apk CalendarProvider.apk               CalendarProvider.apk 日历储存(日历删了,这个也删除)
    CameraGoogle.apk     相机(不能删,4.1后没有此包)
    CertInstaller.apk CertInstaller.apk                CertInstaller.apk 证书(不能删)
    ChromeBookmarksSyncAdapter.apk ChromeBookmarksSyncAdapter.apk    ChromeBookmarksSyncAdapter.apk 书签同步(可删,要用Chrome浏览器同步的不要删除)
        ConfigUpdater.apk 配置更新(不能删,4.2新增)
    Contacts.apk Contacts.apk                      Contacts.apk 通讯录(建议保留,原生通讯录)
    ContactsProvider.apk ContactsProvider.apk               ContactsProvider.apk 联系人储存(建议保留)
      Currents.apk                      Currents.apk 新鲜汇(4.1后新增,可删)
    DefaultContainerService.apk DefaultContainerService.apk       DefaultContainerService.apk 软件包访问(不能删)
    DeskClockGoogle.apk DeskClockGoogle.apk               DeskClockGoogle.apk 时钟(可删)
    DownloadProvider.apk. DownloadProvider.apk               DownloadProvider.apk 下载提供(可删,如果用原生浏览器和Chrome不要删除)
    DownloadProviderUi.apk DownloadProviderUi.apk            DownloadProviderUi.apk 下载提供UI(下载提供删除了,这个也可以删除)
    DrmProvider.apk DrmProvider.apk                   DrmProvider.apk DRM受保护数据存储服务(不能删)
    EmailGoogle.apk EmailGoogle.apk                   EmailGoogle.apk 电子邮件(可删)
    ExchangeGoogle.apk Exchange2Google.apk                Exchange2Google.apk 电子邮件服务(电子邮件删除了,这个也可以删除)
    FaceLock.apk FaceLock.apk                      FaceLock.apk 人脸识别(不能删,删了就不能通过人脸锁屏了)
        FusedLocation.apk 4.2新增
    GalleryGoogle.apk GalleryGoogle.apk                  GalleryGoogle.apk 图库 从4.1包括了相机(不要删,很强大,很好用)
    GenieWidget.apk GenieWidget.apk                   GenieWidget.apk 新闻与天气(可删)
    Gmail.apk Gmail.apk                         Gmail2.apk GMAIL邮箱(可删)
      GmsCore.apk                      GmsCore.apk 谷歌PLAY服务(4.1后新增,可删,不用Google PLAY的可删)
    GoogleBackupTransport.apk GoogleBackupTransport.apk          GoogleBackupTransport.apk 谷歌备份传输(建议不删)
    GoogleContactsSyncAdapter.apk GoogleContactsSyncAdapter.apk    GoogleContactsSyncAdapter.apk 谷歌联系人同步适配器(可删,如果不用谷歌联系人)
      GoogleEars.apk                     GoogleEars.apk 歌曲识别功能(可删)
    GoogleEarth.apk GoogleEarth.apk                   GoogleEarth.apk 谷歌地球(可删)
    GoogleFeedback.apk GoogleFeedback.apk                GoogleFeedback.apk 电子市场反馈(可删)
    GoogleLoginService.apk GoogleLoginService.apk            GoogleLoginService.apk 谷歌账户管理(可删,不用谷歌帐号的可删除)
    GooglePartnerSetup.apk GooglePartnerSetup.apk             GooglePartnerSetup.apk 谷歌合作伙伴(可删)
    GoogleQuickSearchBox.apk     谷歌搜索(可删,4.1后没有此包)
    GoogleServicesFramework.apk GoogleServicesFramework.apk       GoogleServicesFramework.apk 谷歌服务构架(可删)
    GoogleTTS.apk GoogleTTS.apk                      GoogleTTS.apk 文字转语音(可删)
    HoloSpiralWallpaper.apk HoloSpiralWallpaper.apk          HoloSpiralWallpaper.apk 壁纸相关(不能删)
    HTMLViewer.apk HTMLViewer.apk                     HTMLViewer.apk HTML查看器(可删)
      InputDevices.apk                  InputDevices.apk 4.1后新增(不能删)
    KeyChain.apk KeyChain.apk                      KeyChain.apk 密码管理服务(不能删)
    LatinImeDictionaryPack.apk LatinImeDictionaryPack.apk       LatinImeDictionaryPack.apk 词典大全(可删)
    LatinImeGoogle.apk LatinImeGoogle.apk                LatinImeGoogle.apk 安卓键盘(可删)
    Launcher2.apk Launcher2.apk                     Launcher2.apk 启动器(不能删)
    LiveWallpapers.apk LiveWallpapers.apk                LiveWallpapers.apk 动态壁纸(可删)
    LiveWallpapersPicker.apk LiveWallpapersPicker.apk          LiveWallpapersPicker.apk 动态壁纸选择器(可删)
      Magazines.apk                      Magazines.apk 谷歌杂志(4.1后新增,可删)
    Map.apk Maps.apk                         Maps.apk 地图(可删)
    MediaProvider.apk MediaProvider.apk                  MediaProvider.apk 媒体储存(不能删)
    MediaUploader.apk MediaUploader.apk                MediaUploader.apk 上传的内容(不能删,删除之后无法上传彩信)
    Microbes.apk     微生物动态壁纸(可删,4.1后没有此包)
    Mms.apk Mms.apk                            Mms.apk 原生短信(不能删)
    Music2.apk Music2.apk                        Music2.apk 音乐(可删)
    MusicFX.apk MusicFX.apk                        MusicFX.apk 音乐音效(可删)
    NetworkLocation.apk NetworkLocation.apk               NetworkLocation.apk 提供网络位置(可删)
    Nfc.apk Nfc.apk                            Nfc.apk 近场通讯(不用NFC的可删)
    NoiseField.apk NoiseField.apk                   NoiseField.apk 动态壁纸(可删)
    OneTimeInitializer.apk OneTimeInitializer.apk             OneTimeInitializer.apk 初次启动初始化(建议不删)
    PackageInstaller.apk PackageInstaller.apk             PackageInstaller.apk 打包安装管理(不能删)
    PhaseBeam.apk PhaseBeam.apk                      PhaseBeam.apk 动态壁纸(可删)
    Phone.apk Phone.apk                         Phone.apk 手机拨号器(不能删)
    Phoneskyapk Phonesky.apk                      Phonesky.apk Google play电子市场(可删)
        PhotoTable.apk 照片编辑器(不能删,4.2新增)
    PlusOne.apk PlusOne.apk                      PlusOne.apk google+社区软件(可删)
    Settings.apk Settings.apk                      Settings.apk 设置(不能删)
    SettingsProvider.apk SettingsProvider.apk             SettingsProvider.apk 设置储存(不能删)
    SetupWizard.apk SetupWizard.apk                   SetupWizard.apk 设置向导(不能删)
    SharedStorageBackup.apk SharedStorageBackup.apk          SharedStorageBackup.apk 共享存储备份(不能删)
    SoundRecorder.apk SoundRecorder.apk                  SoundRecorder.apk 录音机(建议不删)
    Stk.apx Stk.apk                           Stk.apk SIM卡管理程序(不能删)
    Street.apk Street.apk                         Street.apk 谷歌街景(可删)
    Superuser.apk Superuser.apk                     Superuser.apk Root后才有的(当然不能删)
    SystemUI.apk SystemUI.apk                      SystemUI.apk 系统用户界面(不能删)
    TagGoogle.apk TagGoogle.apk                     TagGoogle.apk NFC标记(NFC删了之后这个也要删)
    Talk.apk Talk.apk                           Talk.apk 谷歌talk(可删)
    Talkback.apk talkback.apk                      talkback.apk 盲人辅助(可删)
    TelephonyProvider.apk TelephonyProvider.apk             TelephonyProvider.apk 电话信息储存(不能删)
    Thinkfree.apk Thinkfree.apk                     Thinkfree.apk 文档软件(可删)
    UserDictionaryProvider.apk UserDictionaryProvider.apk         UserDictionaryProvider.apk 我的字典(不能删)
      Velvet.apk                        Velvet.apk 谷歌搜索(4.1后新增,可删,要用谷歌搜索的别删)
    VideoEditorGoogle.apk VideoEditorGoogle.apk             VideoEditorGoogle.apk 电影(可删)
    Videos.apk Videos.apk                        Videos.apk 视频(可删)
    VisualizationWallpapers.apk VisualizationWallpapers.apk       VisualizationWallpapers.apk 可视化壁纸(可删)
    VoiceDialer.apk     语音拨号器(可删,4.1后没有此包)
    VoiceSearch.apk     语音搜索(可删,4.1后没有此包)
      VoiceSearchStub.apk   VoiceSearchStub.apk 语音搜索(4.1后改名了 不用语音搜索的可删)
    科学上网Dialogs.apk 科学上网Dialogs.apk                     科学上网Dialogs.apk 科学上网连接上网管理(建议不删)
    YouTube.apk YouTube.apk                      YouTube.apk YouTube视频网站(可删)


    展开全文
  • 本篇文章翻译自cordova官网:其地址为: ... Android webview ...这篇文章指导用户在Android原生软件里嵌入一个基于cordova的网页页面(webview)。 这些部件是怎样在互相之间交流数据请查看:Applicatio
  • BB10终端 本机 BB10 Cascades 终端仿真器。
  • 4.2原生软件可精简内容详细列表 http://bbs.gfan.com/android-5531642-1-1.html Andriod 4.2系统包 说明 ApplicationsProvider.apk 应用程序存储、 程序管理器(不可删)...
  • 移动端app开发,原生开发与混合开发的区别

    万次阅读 多人点赞 2019-09-26 18:47:01
    目前市场上主流的APP分为三种:原生APP、Web APP(即HTML5)和混合APP三种,相...原生开发(Native App开发),是在Android、IOS等移动平台上利用提供的开发语言、开发类库、开发工具进行App软件开发。比如Android是...
  • BB10安装软件教程

    2013-12-11 19:52:46
    BB10安装BAR软件详细教程.黑莓Q10 Z10 详细软件安装转制教程
  • 入手 M1 Mac 之前,你首先了解一下Apple Silicon M1原生应用和Rosetta2。 关于Apple Silicon M1 什么是Apple Silicon M1 M1是Apple的第一个定制芯片系统,可用于其Mac计算机产品线。自2006年以来,所有Mac均配备了...
  • 安卓Android苹果IOS双端多用途通讯录短信定位获取系统,hbiulderX打包出来的和原生APP一样 源码适用于:金融业务型公司(当你和客人达成资金担保合作协议,在抄录其50个备用联系人的时候,直接进行读取,省去了一...
  • 戳蓝字“CSDN云计算”关注我们哦!本文旨在揭示现代软件行业的关键主题——云原生应用程序。这篇文章涉及微服务、容器和无服务器应用程序。在这里,我们将讨论这些技术的实际优点...
  • 来源|comparethecloud翻译 | 天道酬勤,责编 |Carol出品 | CSDN云计算(ID:CSDNcloud)云应用程序是热门话题。很多时候,我们会遇到像云原生应用程...
  • Mac 里面安装的这么多App,如何检查哪些是原生执行,哪些是转译执行? M1 Mac 中App 原生执行与转译执行效能有差 前段提到,因为处理器架构不同,所以在执行不同架构的App 需要经过转译后才能使用,因此苹果也特别...
  • 第二届CNTC云原生技术大会PPT关于讲解云原生技术架构思维ppt 谐云丁轶群—从云到边缘,边缘...顺势而微-微服务在软件开发中的落地实践-20181026 CNTC 陈屹力——云原生应用标准体系建设 阿里谷朴—2018浙大云原生会议
  • 原生App与Web APP优劣势分析

    千次阅读 多人点赞 2019-06-25 10:45:33
    现如今APP开发有两个主流的方向:原生App 以及移动Web App。那么您是否知道这两者有何区别?什么是原生APP,什么是web APP?今天小编在此对二者进行一个对比。 ☛ 什么是原生APP 在智能手机上运行的App应用程序有...
  • [云原生]~云原生简介

    2019-12-08 21:10:28
    原生的主要特征 进一年我们都在使用云原生框架 SpringCloud微服务开发项目,敏捷快速 部署在容器中,解决部署环境差异 使用DevOps自动部署,减少运维压力 微服务 业务功能单一但完整 只对外提供必要的...
  • 安卓系统原生设置APP

    2019-02-22 16:17:45
    安卓系统的原生设置,机顶盒刷机、手机刷机可以用到。
  • 自己对原生软件的理解:直接利用系统底层语言、基于系统原生GUI控件开发的软件。一直偏执的认为原生软件才是真正的软件,其它如vb,java,.net等开发的都是玩具,到了linux下后,才深切感受到的自己的愚昧,实际上...
  • 2020 年随着行业的向前发展,一种新的概念将体现“软件定义一切”的精髓,我们相信这种概念就是混合云。 2020 年,硬件将无处不在,而软件将在硬件鞭长莫及的领域应对日益严重的复杂性。 云的安全性 这个问题很可能...
  • 主要介绍了Android8.1原生系统网络感叹号消除的方法,小编觉得挺不错的,现在分享给大家,也给大家做个参考。一起跟随小编过来看看吧
  • 150讲轻松学习Python网络爬虫

    万人学习 2019-05-16 15:30:54
    2、如果是作为一个其他行业的开发者,比如app开发,web开发,学习爬虫能让你加强对技术的认知,能够开发出更加安全的软件和网站 【课程设计】 一个完整的爬虫程序,无论大小,总体来说可以分成三个步骤,分别是: ...
  • 原生架构下的软件持续交付实践

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 122,766
精华内容 49,106
关键字:

原生软件