精华内容
下载资源
问答
  • 怎样成为一优秀的架构师?

    万次阅读 多人点赞 2019-10-08 17:15:37
    架构师是一既能掌控整体又能洞悉局部瓶颈并依据具体的业务场景给出解决方案的团队领导型人物。看似完美的“人格模型”背后,是艰辛的探索。 架构师不是一人,他需要建立高效卓越的体系,带领团队去攻城略地,在...

    怎样才算是架构师?

    架构师是一个既能掌控整体又能洞悉局部瓶颈并依据具体的业务场景给出解决方案的团队领导型人物。看似完美的“人格模型”背后,是艰辛的探索。

    架构师不是一个人,他需要建立高效卓越的体系,带领团队去攻城略地,在规定的时间内完成项目。

    架构师的分类

    从业界来看对于架构师的理解可以大概区分为:

    • 企业架构师:专注于企业总体 IT 架构的设计。

    • IT 架构师-软件产品架构师:专注于软件产品的研发。

    • IT 架构师-应用架构师:专注于结合企业需求,定制化 IT 解决方案;大部分需要交付的工作包括总体架构、应用架构、数据架构,甚至部署架构。

    • IT 架构师-技术架构师:专注于基础设施,某种软硬件体系,甚至云平台,提交:产品建议、产品选型、部署架构、网络方案,甚至数据中心建设方案等。

    架构师的职责

    架构师需要能够识别定义并确认需求,能够进行系统分解形成整体架构,能够正确地技术选型,能够制定技术规格说明并有效推动实施落地。

    按 TOGAF 的定义,架构师的职责是了解并关注实际上关系重大但未变得过载的一些关键细节和界面,架构师的角色有:理解并解析需求,创建有用的模型,确认、细化并扩展模型,管理架构。

    从项目视图看:

    对接管理部门:汇报技术方案,进度;技术沟通;
    对接客户 PM,项目 PM:协助项目计划,人员管理等。负责所有技术交付物的指导;
    对接业务部门和需求人员:了解和挖掘痛点,帮忙梳理高级业务需求,指导需求工艺;
    对接开发:产品支持、技术指导、架构指导;
    对接测试:配合测试计划和工艺制定。配合性能测试或者非功能性测试;
    对接运维:产品支持,运维支持;
    对接配置&环境:产品支持;
    .......

    架构原则

    设计原则就是架构设计的指导思想,它指导我们如何将数据和函数组织成类,如何将类链接起来成为组件和程序。反向来说,架构的主要工作就是将软件拆解为组件,设计原则指导我们如何拆解、拆解的粒度、组件间依赖的方向、组件解耦的方式等。

    设计原则有很多,我们进行架构设计的主导原则是 OCP(开闭原则),在类和代码的层级上有:SRP(单一职责原则)、LSP(里氏替换原则)、ISP(接口隔离原则)、DIP(依赖反转原则);在组件的层级上有:REP(复用、发布等同原则)、CCP(共同闭包原则)、CRP(共同复用原则),处理组件依赖问题的三原则:无依赖环原则、稳定依赖原则、稳定抽象原则。

    设计原则

    1、OCP(开闭原则):设计良好的软件应该易于扩展,同时抗拒修改。这是我们进行架构设计的主导原则,其他的原则都为这条原则服务。

    2、SRP(单一职责原则):任何一个软件模块,都应该有且只有一个被修改的原因,“被修改的原因“指系统的用户或所有者,翻译一下就是,任何模块只对一个用户的价值负责,该原则指导我们如何拆分组件。

    举个例子,CTO 和 COO 都要统计员工的工时,当前他们要求的统计方式可能是相同的,我们复用一套代码,这时 COO 说周末的工时统计要乘以二,按照这个需求修改完代码,CTO 可能就要过来骂街了。当然这是个非常浅显的例子,实际项目中也有很多代码服务于多个价值主体,这带来很大的探秘成本和修改风险,另外,当一份代码有多个所有者时,就会产生代码合并冲突的问题。

    3、LSP(里氏替换原则):当用同一接口的不同实现互相替换时,系统的行为应该保持不变。该原则指导的是接口与其实现方式。

    你一定很疑惑,实现了同一个接口,他们的行为也肯定是一致的呀,还真不一定。假设认为矩形的系统行为是:面积=宽*高,让正方形实现矩形的接口,在调用 setW 和 setH 时,正方形做的其实是同一个事情,设置它的边长。这时下边的单元测试用矩形能通过,用正方形就不行,实现同样的接口,但是系统行为变了,这是违反 LSP 的经典案例。

    Rectangle r = ... 
    r.setW(5); 
    r.setH(2); 
    assert(r.area() == 10);
    

    4、ISP(接口隔离原则):不依赖任何不需要的方法、类或组件。该原则指导我们的接口设计。当我们依赖一个接口但只用到了其中的部分方法时,其实我们已经依赖了不需要的方法或类,当这些方法或类有变更时,会引起我们类的重新编译,或者引起我们组件的重新部署,这些都是不必要的。所以我们最好定义个小接口,把用到的方法拆出来。

    5、DIP(依赖反转原则):指一种特定的解耦(传统的依赖关系创建在高层次上,而具体的策略设置则应用在低层次的模块上)形式,使得高层次的模块不依赖于低层次的模块的实现细节,依赖关系被颠倒(反转),从而使得低层次模块依赖于高层次模块的需求抽象。

    跨越组建边界的依赖方向永远与控制流的方向相反。该原则指导我们设计组件间依赖的方向。

    依赖反转原则是个可操作性非常强的原则,当你要修改组件间的依赖方向时,将需要进行组件间通信的类抽象为接口,接口放在边界的哪边,依赖就指向哪边。

    6、REP(复用、发布等同原则):软件复用的最小粒度应等同于其发布的最小粒度。直白地说,就是要复用一段代码就把它抽成组件,该原则指导我们组件拆分的粒度。

    7、CCP(共同闭包原则):为了相同目的而同时修改的类,应该放在同一个组件中。CCP 原则是 SRP 原则在组件层面的描述。该原则指导我们组件拆分的粒度。

    对大部分应用程序而言,可维护性的重要性远远大于可复用性,由同一个原因引起的代码修改,最好在同一个组件中,如果分散在多个组件中,那么开发、提交、部署的成本都会上升。

    8、CRP(共同复用原则):不要强迫一个组件依赖它不需要的东西。CRP 原则是 ISP原则在组件层面的描述。该原则指导我们组件拆分的粒度。

    相信你一定有这种经历,集成了组件 A,但组件 A 依赖了组件 B、C。即使组件 B、C 你完全用不到,也不得不集成进来。这是因为你只用到了组件 A 的部分能力,组件 A 中额外的能力带来了额外的依赖。如果遵循共同复用原则,你需要把 A 拆分,只保留你要用的部分。

    REP、CCP、CRP 三个原则之间存在彼此竞争的关系,REP 和 CCP 是黏合性原则,它们会让组件变得更大,而 CRP 原则是排除性原则,它会让组件变小。遵守REP、CCP 而忽略 CRP,就会依赖了太多没有用到的组件和类,而这些组件或类的变动会导致你自己的组件进行太多不必要的发布;遵守 REP、CRP 而忽略 CCP,因为组件拆分的太细了,一个需求变更可能要改 n 个组件,带来的成本也是巨大的。

    指导原则

    除了上述设计原则,还有一些重要的指导原则如下:

    1、N+1设计:系统中的每个组件都应做到没有单点故障;

    2、回滚设计:确保系统可以向前兼容,在系统升级时应能有办法回滚版本;

    3、禁用设计:应该提供控制具体功能是否可用的配置,在系统出现故障时能够快速下线功能;

    4、监控设计:在设计阶段就要考虑监控的手段,便于有效的排查问题,比如引入traceId、业务身份 Id 便于排查监控问题;

    5、多活数据中心设计:若系统需要极高的高可用,应考虑在多地实施数据中心进行多活,至少在一个机房断电的情况下系统依然可用;

    6、采用成熟的技术:刚开发的或开源的技术往往存在很多隐藏的 bug,出了问题没有很好的商业支持可能会是一个灾难;

    7、资源隔离设计:应避免单一业务占用全部资源;

    8、架构水平扩展设计:系统只有做到能水平扩展,才能有效避免瓶颈问题;

    9、非核心则购买的原则:非核心功能若需要占用大量的研发资源才能解决,则考虑购买成熟的产品;

    10、使用商用硬件:商用硬件能有效降低硬件故障的机率;

    11、快速迭代:系统应该快速开发小功能模块,尽快上线进行验证,早日发现问题大大降低系统交付的风险;

    12、无状态设计:服务接口应该做成无状态的,当前接口的访问不依赖于接口上次访问的状态。

    架构师知道了职责,具备很好的架构思维,掌握了通用的架构框架和方法论,使用架构原则进行架构设计,不同的业务和系统要求不一样,那么有没有针对不同场景的系统架构设计?下文就针对分布式架构演进、单元化架构、面向服务 SOA 架构、微服务架构、Serverless 架构进行介绍,以便于我们在实际运用中进行参考使用。

    具备架构师的思维

    架构师职责明确了,那么有什么架构思维可以指导架构设计呢?请看下述的架构思维。

    1、自顶向下构建架构

    要点主要如下:

    1)首先定义问题,而定义问题中最重要的是定义客户的问题。定义问题,特别是识别出关键问题,关键问题是对客户有体感,能够解决客户痛点,通过一定的数据化来衡量识别出来,关键问题要优先给出解决方案。

    2)问题定义务必加入时间维度,把手段/方案和问题定义区分开来。

    3)问题定义中,需要对问题进行升层思考后再进行升维思考,从而真正抓到问题的本质,理清和挖掘清楚需求;要善用第一性原理思维进行分析思考问题。

    4)问题解决原则:先解决客户的问题(使命),然后才能解决自己的问题(愿景);务必记住不是强调我们怎么样,而是我们能为客户具体解决什么问题,然后才是我们变成什么,从而怎么样去更好得服务客户。

    5)善用多种方法对客户问题进行分析,转换成我们产品或者平台需要提供的能力,比如仓储系统 WMS 可以提供哪些商业能力。

    6)对我们的现有的流程和能力模型进行梳理,找到需要提升的地方,升层思考和升维思考真正明确提升部分。

    7)定义指标,并能够对指标进行拆解,然后进行数学建模。

    8)将抽象出来的能力诉求转换成技术挑战,此步对于技术人员来说相当于找到了靶子,可以进行方案的设计了,需要结合自底向上的架构推导方式。

    9)创新可以是业务创新,也可以是产品创新,也可以是技术创新,也可以是运营创新,升层思考、升维思考,使用第一性原理思维、生物学(进化论--进化=变异+选择+隔离、熵增定律、分形和涌现)思维等哲科思维可以帮助我们在业务,产品,技术上发现不同的创新可能。可以说哲科思维是架构师的灵魂思维。

    2、自底向上推导应用架构

    先根据业务流程,分解出系统时序图,根据时序图开始对模块进行归纳,从而得到粒度更大的模块,模块的组合/聚合构建整个系统架构。

    基本上应用逻辑架构的推导有4个子路径,他们分别是:

    • 业务概念架构:业务概念架构来自于业务概念模型和业务流程;

    • 系统模型:来自于业务概念模型;

    • 系统流程:来自业务流程;

    • 非功能性的系统支撑:来自对性能、稳定性、成本的需要。

    效率、稳定性、性能是最影响逻辑架构落地成物理架构的三大主要因素,所以从逻辑架构到物理架构,一定需要先对效率、稳定性和性能做出明确的量化要求。

    自底向上重度依赖于演绎和归纳。

    如果是产品方案已经明确,程序员需要理解这个业务需求,并根据产品方案推导出架构,此时一般使用自底向上的方法,而领域建模就是这种自底向上的分析方法。

    对于自底向上的分析方法,如果提炼一下关键词,会得到如下两个关键词:

    1)演绎:演绎就是逻辑推导,越是底层的,越需要演绎:

    • 从用例到业务模型就属于演绎;

    • 从业务模型到系统模型也属于演绎;

    • 根据目前的问题,推导出要实施某种稳定性措施,这是也是演绎。

    2)归纳:这里的归纳是根据事物的某个维度来进行归类,越是高层的,越需要归纳:

    • 问题空间模块划分属于归纳;

    • 逻辑架构中有部分也属于归纳;

    • 根据一堆稳定性问题,归纳出,事前,事中,事后都需要做对应的操作,是就是根据时间维度来进行归纳。

    3、领域驱动设计架构

    大部分传统架构都是基于领域模型分析架构,典型的领域实现模型设计可以参考DDD(领域驱动设计),详细可以参考《实现领域驱动设计》这本书,另外《UML和模式应用》在领域建模实操方面比较好,前者偏理论了解,后者便于落地实践。

    领域划分设计步骤:

    (1) 对用户需求场景分析,识别出业务全维度 Use Case。

    (2) 分析模型鲁棒图,识别出业务场景中所有的实体对象。鲁棒图 —— 是需求设计过程中使用的一种方法(鲁棒性分析),通过鲁棒分析法可以让设计人员更清晰,更全面地了解需求。它通常使用在需求分析后及需求设计前做软件架构分析之用,它主要注重于功能需求的设计分析工作。需求规格说明书为其输入信息,设计模型为其输出信息。它是从功能需求向设计方案过渡的第一步,重点是识别组成软件系统的高级职责模块、规划模块之间的关系。鲁棒图包含三种图形:边界、控制、实体,三个图形如下:

    (3) 领域划分,将所有识别出的实体对象进行分类。

    (4) 评估域划分合理性,并进行优化。

    4、基于数据驱动设计架构

    随着 IoT、大数据和人工智能的发展,以领域驱动的方式进行架构往往满足不了需求或者达不到预期的效果,在大数据时代,在大数据应用场景,我们需要转变思维,从领域分析升维到基于大数据统计分析结果来进行业务架构、应用架构、数据架构和技术架构。这里需要架构师具备数理统计分析的基础和 BI 的能力,以数据思维来架构系统,典型的系统像阿里的数据分析平台采云间和菜鸟的数据分析平台 FBI。

    上述四种思维,往往在架构设计中是融合使用的,需要根据业务或者系统的需求来选择侧重思维方式。

    单元化架构,微服务架构以及 Serveless 架构

    单元化架构

    1. 单元化是什么

    单元化架构是从并行计算领域发展而来。在分布式服务设计领域,一个单元(Cell)就是满足某个分区所有业务操作的自包含的安装。而一个分区(Shard),则是整体数据集的一个子集,如果你用尾号来划分用户,那同样尾号的那部分用户就可以认为是一个分区。单元化就是将一个服务设计改造让其符合单元特征的过程。

    单元化架构,为什么要用以及我们如何做到

    图 1 :洋葱细胞的显微镜截图,单元化要达到的目的就是让每个单元像细胞一样独立工作

    在传统的服务化架构下(如下图),服务是分层的,每一层使用不同的分区算法,每一层都有不同数量的节点,上层节点随机选择下层节点。当然这个随机是比较而言的。

    单元化架构,为什么要用以及我们如何做到

    图 2 :传统的服务化架构,为伸缩性设计,上层节点随机选择下层节点

    与其不同的是,在单元化架构下,服务虽然分层划分,但每个单元自成一体。按照层次来讲的话,所有层使用相同的分区算法,每一层都有相同数量的节点,上层节点也会访问指定的下层节点。因为他们已经在一起。

    单元化架构,为什么要用以及我们如何做到

    图 3 :单元化架构,为性能和隔离性而设计,上层节点访问指定下层节点

    2. 为什么要用单元化

    在性能追求和成本限制的情况下,我们需要找到一种合适的方法来满足服务需求。在传统的分布式服务设计,我们考虑的更多是每个服务的可伸缩性,当各个服务独立设计时你就要在每一层进行伸缩性的考虑。这是服务化设计(SOA)流行的原因,我们需要每个服务能够单独水平扩展。

    但是在摩尔定律下,随着硬件的不断升级,计算机硬件能力已经越来越强,CPU 越来越快,内存越来越大,网络越来越宽。这让我们看到了在单台机器上垂直扩展的机会。尤其是当你遇到一个性能要求和容量增长可以预期的业务,单元化给我们提供另外的机会,让我们可以有效降低资源的使用,提供更高性能的服务。

    总体而言,更高性能更低成本是我们的主要目标,而经过单元化改造,我们得以用更少(约二分之一)的机器,获得了比原来更高(接近百倍)的性能。性能的提升很大部分原因在于服务的本地化,而服务的集成部署又进一步降低了资源的使用。

    当然除了性能收益,如果你做到了,你会发现还有很多收益,比如更好的隔离性,包括请求隔离和资源隔离,比如更友好的升级,产品可以灰度发布等。单元化改造后对高峰的应对以及扩容方式等问题,各位可以参考#微博春节技术保障系列#中的单元化架构文章,也不在此一一赘述。

    3. 我们如何做到

    此次单元化改造基于微博现有的业务,因此这里也先行介绍一下。粉丝服务平台是微博的内容推送系统(代号 Castalia),可为 V 用户提供向其粉丝推送高质量内容的高速通道(单元化之后已到达百万条每秒)。整个服务涉及用户筛选、发送计费、屏蔽检查、限流控制和消息群发等多个子服务。由于改造思想相通,这里以用户筛选和消息群发两个服务为例,下面两图分别为商业群发在服务化思想和单元化思想下不同的架构。

    单元化架构,为什么要用以及我们如何做到

    图 4: 服务化思想下的商业群发架构设计(旧版)

    单元化架构,为什么要用以及我们如何做到

    图 5 :商业群发在单元化思想下的架构设计(新版)

    对于筛选服务,在服务化架构里,需要去粉丝服务获取粉丝关系,然后去特征服务进行用户特征筛选,最后将筛选结果传输到群发服务器上;而在单元化架构里,粉丝关系直接就在本地文件中,用户特征服务也在本地,最后的筛选结果再不需要传输。服务本地化(粉丝关系和用户特征存储)减去了网络开销,降低了服务延时,还同时提高了访问速度和稳定性,而筛选结果本地存储又进一步节省了带宽并降低了延迟。以百万粉丝为例,每次网络操作的减少节省带宽 8M 左右,延时也从 400ms 降为 0。

    群发服务同样如此。由于在服务化架构里,我们使用 MySQL 和 Memcache 的方案,由于关系数据库的写入性能问题,中间还有队列以及相应的队列处理机,所有四个模块都有单独的机器提供服务,而在单元化架构里,四合一之后,只需要一套机器。当然机器的配置可能会有所提升,但真正计算之后你就会发现其实影响微乎其微。原因除了前面介绍的硬件增长空间外,上架机器的基本配置变高也是一个原因。而且,在单元化方案里,当我们把缓存部署在本地之后,其性能还有了额外的 20% 提升。

    一些业务特有问题

    不过群发这个场景,我们也遇到了一些特定的问题,一是分区问题,一是作业管理。这里也与各位分享下我们的解决方法。

    1. 分区问题

      分区问题其实是每个服务都会遇到的,但单元化后的挑战在于让所有服务都适配同一分区算法,在我们的场景下,我们按照接收者进行了分区,即从底层往上,每一层都来适配此分区算法。

      这里有特例的是用户特征和屏蔽服务,由于总体容量都很小,我们就没有对数据进行分区,所有单元内都是同一套全量数据,都是一个外部全量库的从库。不过由于本单元内的上层服务的关系,只有属于本分区的用户数据被访问到。所以,适配同一分区算法在某种程度上讲,可以兼容即可。

    2. 作业管理

      按照前面的分区方式,将群发服务的整体架构变成了一个类似 Scatter-Gather+CQRS 的方案,因为 Gather 不是一个请求处理的必须要素。也就是说,一个群发请求会被扩散到所有单元中,每个单元都要针对自己分区内的用户处理这个群发请求。

      广播方式的引入,使得我们首先需要在前端机进行分单元作业的处理监控,我们在此增加了持久化队列来解决。同时,由于单元内每个服务也都是单独维护的,作业可能在任何时间中断,因此每个作业在单元内的状态也都是有记录的,以此来达到作业的可重入和幂等性,也就可以保证每个作业都可以在任何时间重做,但不会重复执行。

    除此之外,我们还对服务器进行了更为精细的控制,使用 CPU 绑定提高多服务集成部署时的整体效率,使用多硬盘设计保证每个服务的 IO 性能,通过主从单元的读写分离来提高整体服务等等。

    参考文章:https://www.infoq.cn/article/how-weibo-do-unit-architecture/

    SOA架构

    SOA(Service-Oriented Architecture,面向服务的架构)是一个组件模型,它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的,它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。面向服务架构,它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。服务层是 SOA 的基础,可以直接被应用调用,从而有效控制系统中与软件代理交互的人为依赖性。

    SOA的实施具有几个鲜明的基本特征。实施 SOA 的关键目标是实现企业 IT 资产的最大化作用。要实现这一目标,就要在实施 SOA 的过程中牢记以下特征:

    • 可从企业外部访问;

    • 随时可用;

    • 粗粒度的服务接口分级;

    • 松散耦合;

    • 可重用的服务;

    • 服务接口设计管理;

    • 标准化的服务接口;

    • 支持各种消息模式;

    • 精确定义的服务契约。

    为了实现 SOA,企业需要一个服务架构,下图显示了一个例子:

    在上图中, 服务消费者(service consumer)可以通过发送消息来调用服务。这些消息由一个服务总线(service bus)转换后发送给适当的服务实现。这种服务架构可以提供一个业务规则引(business rules engine),该引擎容许业务规则被合并在一个服务里或多个服务里。这种架构也提供了一个服务管理基础(service management infrastructure),用来管理服务,类似审核,列表(billing),日志等功能。

    此外,该架构给企业提供了灵活的业务流程,更好地处理控制请求(regulatory requirement),例如Sarbanes Oxley(SOX),并且可以在不影响其他服务的情况下更改某项服务。

    微服务架构

    先来看看传统的 web 开发方式,通过对比比较容易理解什么是 Microservice Architecture。和 Microservice 相对应的,这种方式一般被称为 Monolithic(单体式开发)。

    所有的功能打包在一个 WAR包里,基本没有外部依赖(除了容器),部署在一个JEE容器(Tomcat,JBoss,WebLogic)里,包含了 DO/DAO,Service,UI 等所有逻辑。

    1、优点:

    • 开发简单,集中式管理;

    • 基本不会重复开发;

    • 功能都在本地,没有分布式的管理和调用消耗。

    2、缺点:

    • 效率低:开发都在同一个项目改代码,相互等待,冲突不断;

    • 维护难:代码功功能耦合在一起,新人不知道何从下手;

    • 不灵活:构建时间长,任何小修改都要重构整个项目,耗时;

    • 稳定性差:一个微小的问题,都可能导致整个应用挂掉;

    • 扩展性不够:无法满足高并发下的业务需求。

    3、常见的系统架构遵循的三个标准和业务驱动力:

    • 提高敏捷性:及时响应业务需求,促进企业发展;

    • 提升用户体验:提升用户体验,减少用户流失;

    • 降低成本:降低增加产品、客户或业务方案的成本。

    4、基于微服务架构的设计:

    目的:有效的拆分应用,实现敏捷开发和部署。

    关于微服务的一个形象表达:

    • X轴:运行多个负载均衡器之后的运行实例;

    • Y轴:将应用进一步分解为微服务(分库);

    • Z轴:大数据量时,将服务分区(分表)。

    5、SOA和微服务的区别:

    • SOA喜欢重用,微服务喜欢重写;

    • SOA喜欢水平服务,微服务喜欢垂直服务;

    • SOA喜欢自上而下,微服务喜欢自下而上。

    Serverless架构

    1、思想:无服务器是一种架构理念,其核心思想是将提供服务资源的基础设施抽象成各种服务,以 API 接口的方式供给用户按需调用,真正做到按需伸缩、按使用收费。

    2、优势:消除了对传统的海量持续在线服务器组件的需求,降低了开发和运维的复杂性,降低运营成本并缩短了业务系统的交付周期,使得用户能够专注在价值密度更高的业务逻辑的开发上。

    3、内容:目前业界较为公认的无服务器架构主要包括两个方面,即提供计算资源的函数服务平台 FaaS,以及提供托管云服务的后端服务 BaaS。

    函数即服务(Function as a Service):是一项基于事件驱动的函数托管计算服务。通过函数服务,开发者只需要编写业务函数代码并设置运行的条件,无需配置和管理服务器等基础设施,函数代码运行在无状态的容器中,由事件触发且短暂易失,并完全由第三方管理,基础设施对应用开发者完全透明。函数以弹性、高可靠的方式运行,并且按实际执行资源计费,不执行不产生费用。

    后端即服务(Backend as a Service):BaaS 覆盖了应用可能依赖的所有第三方服务,如云数据库、身份验证、对象存储等服务,开发人员通过 API 和由 BaaS 服务商提供的 SDK,能够集成所需的所有后端功能,而无需构建后端应用,更不必管理虚拟机或容器等基础设施,就能保证应用的正常运行。

    三个less感觉很好:

    • Codeless 对应的是服务开发,实现了源代码托管,你只需要关注你的代码实现,而不需要关心你的代码在哪,因为在整个开发过程中你都不会感受到代码库和代码分支的存在。

    • Applicationless 对应的是服务发布,在服务化框架下,你的服务发布不再需要申请应用,也不需要关注你的应用在哪。

    • Serverless 对应的则是服务运维,有了 Serverless 化能力,你不再需要关注你的机器资源,Servlerless 会帮你搞定机器资源的弹性扩缩容。

    架构师在完成上述架构设计后,最终是需要协同利益相关方一起按项目化运作落地拿结果,那么应该如何保证利益相关方在项目落地的满意度,如何保证按照架构很好的拿到项目成功的结果呢?架构管理能力是架构师非常重要的能力。

    架构师管理架构双赢模型

    架构结果管理

    优秀架构师必须掌握的几种架构思维

    架构的本质是管理复杂性,抽象、分层、分治和演化思维是我们工程师/架构师应对和管理复杂性的四种最基本武器。

    最近团队来了一些新人,有些有一定工作经验,是以高级工程师/架构师身份进来的,但我发现他们大部分人思维偏应用和细节,抽象能力弱。所以作为团队技术培训的一部分,我整理了这篇文章,希望对他们树立正确的架构设计思维有帮助。我认为,对思维习惯和思考能力的培养,其重要性远远大于对实际技术工具的掌握。

    由于文章内容较长,所以我把它分成两篇小文章,在第一篇《优秀架构师必须掌握的架构思维》中,我会先介绍抽象、分层、分治和演化这四种应对复杂性的基本思维。在第二篇《四个架构设计案例及其思维方式》中,我会通过四个案例,讲解如何综合运用这些思维,分别对小型系统,中型系统,基础架构,甚至是组织技术体系进行架构和设计。

    一、抽象思维

    如果要问软件研发/系统架构中最重要的能力是什么,我会毫不犹豫回答是抽象能力。抽象(abstraction)这个词大家经常听到,但是真正理解和能讲清楚什么是抽象的人少之又少。抽象其实是这样定义的:

    对某种事物进行简化表示或描述的过程,抽象让我们关注要素,隐藏额外细节。

    举一个例子,见下图:

    你看到什么?你看到的是一扇门,对不对?你看到的不是木头,也不是碳原子,这个门就是抽象,而木头或者碳原子是细节。另外你可以看到门上有个门把手,你看到的不是铁,也不是铁原子,门把手就是抽象,铁和铁原子是细节。

    在系统架构和设计中,抽象帮助我们从大处着眼(get our mind about big picture),隐藏细节(temporarily hide details)。抽象能力的强弱,直接决定我们所能解决问题的复杂性和规模大小。

    下图是我们小时候玩的积木,我发现小时候喜欢玩搭积木的,并且搭得快和好的小朋友,一般抽象能力都比较强。

    上图右边的积木城堡就是抽象,这个城堡如果你细看的话,它其实还是由若干个子模块组成,这些模块是子抽象单元,左边的各种形状的积木是细节。搭积木的时候,小朋友脑袋里头先有一个城堡的大图(抽象),然后他/她大脑里头会有一个初步的子模块分解(潜意识中完成),然用利用积木搭建每一个子模块,最终拼装出最后的城堡。这里头有一个自顶向下的分治设计,然后自底向上的组合过程,这个分治思维非常重要,我们后面会讲。

    我认为软件系统架构设计和小朋友搭积木无本质差异,只是解决的问题域和规模不同罢了。架构师先要在大脑中形成抽象概念,然后是子模块分解,然后是依次实现子模块,最后将子模块拼装组合起来,形成最后系统。所以我常说编程和架构设计就是搭积木,优秀的架构师受职业习惯影响,眼睛里看到的世界都是模块化拼装组合式的。

    抽象能力不仅对软件系统架构设计重要,对建筑、商业、管理等人类其它领域活动同样非常重要。其实可以这样认为,我们生存的世界都是在抽象的基础上构建起来的,离开抽象人类将寸步难行。

    这里顺便提一下抽象层次跳跃问题,这个在开发中是蛮普遍的。有经验的程序员写代码会保持抽象层次的一致性,代码读起来像讲故事,比较清晰易于理解;而没有经验的程序员会有明显的抽象层次跳跃问题,代码读起来就比较累,这个是抽象能力不足造成。举个例子:

    一个电商网站在处理订单时,一般会走这样一个流程:

    1. 更新库存(InventoryUpdate)
    2. 打折计算(Discounting)
    3. 支付卡校验(PaycardVerification)
    4. 支付(Pay)
    5. 送货(Shipping)

    上述流程中的抽象是在同一个层次上的,比较清晰易于理解,但是没有经验的程序员在实现这个流程的时候,代码层次会跳,比方说主流程到支付卡校验一块,他的代码会突然跳出一行某银行API远程调用,这个就是抽象跳跃,银行API调用是细节,应该封装在PaycardVerification这个抽象里头。

    二、分层思维

    除了抽象,分层也是我们应对和管理复杂性的基本思维武器,如下图,为了构建一套复杂系统,我们把整个系统划分成若干个层次,每一层专注解决某个领域的问题,并向上提供服务。有些层次是纵向的,它贯穿所有其它层次,称为共享层。分层也可以认为是抽象的一种方式,将系统抽象分解成若干层次化的模块。

    分层架构的案例很多,一个中小型的Spring Web应用程序,我们一般会设计成三层架构:

    操作系统是经典的分层架构,如下图:

    TCP/IP协议栈也是经典的分层架构,如下图:

    如果你关注人类文明演化史,你会发现今天的人类世界也是以分层方式一层层搭建和演化出来的。今天的互联网系统可以认为是现代文明的一个层次,其上是基于互联网的现代商业,其下是现代电子工业基础设施,诸如此类。

    三、分治思维

    分而治之(divide and combine或者split and merge)也是应对和管理复杂性的一般性方法,下图展示一个分治的思维流程:

    对于一个无法一次解决的大问题,我们会先把大问题分解成若干个子问题,如果子问题还无法直接解决,则继续分解成子子问题,直到可以直接解决的程度,这个是分解(divide)的过程;然后将子子问题的解组合拼装成子问题的解,再将子问题的解组合拼装成原问题的解,这个是组合(combine)的过程。

    面试时为了考察候选人的分治思维,我经常会面一个分治题:给你一台8G内存/500G磁盘空间的普通电脑,如何对一个100G的大文件进行排序?假定文件中都是字符串记录,一行约100个字符。

    这是一个典型的分治问题,100G的大文件肯定无法一次加载到内存直接排序,所以需要先切分成若干小问题来解决。那么8G内存的计算机一次大概能排多大的数据量,可以在有限的时间内排完呢?也就是100G的大文件要怎么切法,切成多少份比较合适?这个是考察候选人的时间空间复杂度估算能力,需要一定的计算机组织和算法功底,也需要一定实战经验和sense。实际上8G内存的话,操作系统要用掉一部分,如果用Java开发排序程序,大致JVM可用2~4G内存,基于一般的经验值,一次排1G左右的数据应该没有问题(我实际在计算机上干过1G数据的排序,是OK的)。所以100G的文件需要先切分成100份,每份1G,这样每个子文件可以直接加载到内存进行排序。对于1G数据量的字符串排序,采用Java里头提供的快速排序算法是比较合适的。

    好,经过有限时间的排序(取决于计算机性能,快的一天内能排完),假定100个1G的文件都已经排好了,相当于现在硬盘上有100个已经排好序的文件,但是我们最终需要的是一个排好序的文件,下面该怎么做?这个时候我们需要把已经解决的子问题组合起来,合并成我们需要的最终结果文件。这个时候该采用什么算法呢?这里考察候选人对外排序和归并排序算法的掌握程度,我们可以将100个排好序的文件进行两两归并排序,这样不断重复,我们就会得到50个排好序的文件,每个大小是2G。然后再两两归并,不断重复,直到最后两个文件归并成目标文件,这个文件就是100G并且是排好序的。因为是外排序+归并排序,每次只需要读取当前索引指向的文件记录到内存,进行比较,小的那个输出到目标文件,内存占用极少。另外,上面的算法是两路归并,也可以采用多路归并,甚至是采用堆排序进行优化,但是总体分治思路没有变化。

    总体上这是一个非常好的面试题,除了考察候选人的分治思维之外,还考察对各种排序算法(快排,外排序,归并排序,堆排序)的理解,计算的时间空间复杂度估算,计算机的内外存特性和组织,文件操作等等。实际上能完全回答清楚这个问题的候选人极少,如果有幸被我面到一个,我会如获至宝,因为这个人有成长为优秀架构师的潜质。

    另外,递归也是一种特殊的分治技术,掌握递归技术的开发人员,相当于掌握了一种强大的编程武器,可以解决一些一般开发人员无法解决的问题。比方说最近我的团队在研发一款新的服务框架,其中包括契约解析器(parser),代码生产器(code generator),序列化器(serializer)等组件,里头大量需要用到递归的思维和技术,没有这个思维的开发人员就干不了这个事情。所以我在面试候选人的时候,一般都会出递归相关的编程题,考察候选人的递归思维。

    大自然中递归结构比比皆是,如下图,大家有兴趣不妨思考,大自然通过递归给我们人类何种启示?

    四、演化思维

    社区里头经常有人在讨论:架构是设计出来的?还是演化出来的?我个人基于十多年的经验认为,架构既是设计出来的,同时也是演化出来的,对于互联网系统,基本上可以说是三分设计,七分演化,而且是在设计中演化,在演化中设计,一个不断迭代的过程。

    在互联网软件系统的整个生命周期过程中,前期的设计和开发大致只占三分,在后面的七分时间里,架构师需要根据用户的反馈对架构进行不断的调整。我认为架构师除了要利用自身的架构设计能力,同时也要学会借助用户反馈和进化的力量,推动架构的持续演进,这个就是演化式架构思维。

    当然一开始的架构设计非常重要,架构定系统基本就成型了,不容马虎。同时,优秀的架构师深知,能够不断应对环境变化的系统,才是有生命力的系统,架构的好坏,很大部分取决于它应对变化的灵活性。所以具有演化式思维的架构师,能够在一开始设计时就考虑到后续架构的演化特性,并且将灵活应对变化的能力作为架构设计的主要考量。

    当前,社区正在兴起一种新的架构方法学~演化式架构,微服务架构就是一种典型的演化式架构,它能够快速响应市场用户需求的变化,而单块架构就缺乏这种灵活性。马丁·福乐曾经在其博客上给出过一张微服务架构的演化路线图[附录8.2],可以用来解释设计式思维和演化式思维的差异,如下图所示:

    上面的路线是一开始就直奔微服务架构,其实背后体现的是设计式架构的思维,认为架构师可以完全设计整个系统和它的演化方向。马丁认为这种做法风险非常高,一个是成本高昂,另外一个是刚开始架构师对业务域理解不深,无法清晰划分领域边界,开发出来的系统很可能无法满足用户需求。

    下面的路线是从单块架构开始,随着架构师对业务域理解的不断深入,也随着业务和团队规模的不断扩大,渐进式地把单块架构拆分成微服务架构的思路,这就是演化式架构的思维。如果你观察现实世界中一些互联网公司(例如eBay,阿里,Netflix等等)的系统架构,大部分走得都是演化式架构的路线。

    下图是建筑的演化史,在每个阶段,你可以看到设计的影子,但如果时间线拉得足够长,演化的特性就出来了。

    五、如何培养架构设计思维

    良好的架构设计思维的培养,离不开工作中大量高质量项目的实战锻炼,然后是平时的学习、思考和提炼总结。

    另外,基本的架构设计思维,其实在我们大学计算机课程(比如数据结构和算法)中可以找到影子,只不过当时以学习为主,问题域比较小和理想化。所以大学教育其实非常重要,基本的架构设计思维在那个时候就已经埋下种子,后面工程实践中进一步消化和应用,随着经验的积累,我们能够解决的问题域复杂性和规模逐渐变大,但基本的武器还是抽象、分层和分治等思维。

    我认为一个架构师的成长高度和他大学期间的思维习惯的养成关系密切。我所知道世界一流的互联网公司,例如谷歌等,招聘工程师新人时,对数据结构和算法的要求可以用苛刻来形容,这个可以理解,谷歌级别公司要解决的问题都是超级复杂的,基本思维功底薄弱根本无法应对。

    对于工作经验<5年的工程师新手,如果你大学时代是属于荒废型的,建议工作之余把相关课程再好好自学一把。个人推荐参考美国Berkeley大学的数据结构课程CS61B[附录8.1]进行学习,对建立抽象编程思维非常有帮助,我本人在研究生阶段自学过这门课程,现在回想起来确实受益匪浅,注意该课程中的所有Lab/Homework/Project都要实际动手做一遍,才有好的效果。

    对于演化设计思维,当前的大学教育其实培养很少,相反,当前大学教育大都采用脱离现实场景的简化理想模型,有些还是固定答案的应试教学,这种方式会造成学生思维确定化,不利于培养演化式设计思维。我个人的体会,演化式设计思维更多在实际工作中通过实战锻炼和培养。

    结论

    1. 架构的本质是管理复杂性,抽象、分层、分治和演化思维是架构师征服复杂性的四种根本性武器。
    2. 掌握了抽象、分层、分治和演化这四种基本的武器,你可以设计小到一个类,一个模块,一个子系统,或者一个中型的系统,也可以大到一个公司的基础平台架构,微服务架构,技术体系架构,甚至是组织架构,业务架构等等。
    3. 架构设计不是静态的,而是动态演化的。只有能够不断应对环境变化的系统,才是有生命力的系统。所以即使你掌握了抽象、分层和分治这三种基本思维,仍然需要演化式思维,在设计的同时,借助反馈和进化的力量推动架构的持续演进。
    4. 架构师在关注技术,开发应用的同时,需要定期梳理自己的架构设计思维,积累时间长了,你看待世界事物的方式会发生根本性变化,你会发现我们生活其中的世界,其实也是在抽象、分层、分治和演化的基础上构建起来的。另外架构设计思维的形成,会对你的系统架构设计能力产生重大影响。可以说对抽象、分层、分治和演化掌握的深度和灵活应用的水平,直接决定架构师所能解决问题域的复杂性和规模大小,是区分普通应用型架构师和平台型/系统型架构师的一个分水岭。

    参考:

    1. Berkeley CS61B http://datastructur.es/sp17/
    2. 单块优先 https://www.martinfowler.com/bliki/MonolithFirst.html

    Kotlin 开发者社区

    国内第一Kotlin 开发者社区公众号,主要分享、交流 Kotlin 编程语言、Spring Boot、Android、React.js/Node.js、函数式编程、编程思想等相关主题。

    越是喧嚣的世界,越需要宁静的思考。

    合抱之木,生于毫末;
    九层之台,起于垒土;
    千里之行,始于足下。
    积土成山,风雨兴焉;
    积水成渊,蛟龙生焉;
    积善成德,而神明自得,圣心备焉。
    故不积跬步,无以至千里;
    不积小流,无以成江海。
    骐骥一跃,不能十步;
    驽马十驾,功在不舍。
    锲而舍之,朽木不折;
    锲而不舍,金石可镂。
    蚓无爪牙之利,筋骨之强,上食埃土,下饮黄泉,用心一也。
    蟹六跪而二螯,非蛇鳝之穴无可寄托者,用心躁也。

    展开全文
  • 传统应用开发面临的挑战 服务化实践 ...服务化架构的演进方向 ...主要体现在如下几方面: ...在实际项目分工时,开发都是各自负责几功能,即便开发之间存在功能重叠,往往也会选择自己实现,而...技术架构角度看,


    • 传统应用开发面临的挑战

    • 服务化实践

    • 服务化不是银弹

    • 服务化架构的演进方向

    一 、传统应用开发面临的挑战

    挑战1-- 研发成本高

    主要体现在如下几个方面:

    • 代码重复率高

    在实际项目分工时,开发都是各自负责几个功能,即便开发之间存在功能重叠,往往也会选择自己实现,而不是类库共享,主要原因如下:

    1. 从技术架构角度看,传统垂直架构的特点是本地API接口调用,不存在业务的拆分和互相调用,使用到什么功能就本地开发,非常方便,不需要过度依赖于其它功能模块;

    2. 从考核角度来看,共享很难推行。开发只需要对自己开发的模块交付质量负责,没有义务为他人提供并维护公共类库,这个非常耗费成本;

    3. 时间依赖很难把控:对于公共类库的使用者而言,依赖别人提供此功能,但是功能提供者可能有更重要的事情在做,提供时间无法满足使用者。与其坐等别人提供,还不如自己开发效率高;

    跨地域、跨开发小组协调很困难,业务团队可能跨地域研发,内部通常也会分成多个开发小组,各开发小组之间的协调和沟通成本非常高。

    • 需求变更困难

    代码重复率变高之后,已有功能变更或者新需求加入都会非常困难,以充值缴费功能为例,不同的充值渠道开发了相同的限额保护功能,当限额保护功能发生变更之后,所有重复开发的限额保护功能都需要重新修改和测试,很容易出现修改不一致或者被遗漏,导致部分渠道充值功能正常,部分存在Bug的问题,示例如下:

    华为架构师8年经验谈:从单体架构到微服务的服务化演进之路

    华为架构师8年经验谈:从单体架构到微服务的服务化演进之路

    • 无法满足新业务快速创新和敏捷交付

    华为架构师8年经验谈:从单体架构到微服务的服务化演进之路

    挑战2-- 运维效率低

    在传统的MVC架构中,业务流程是由一长串本地接口或者方法调用串联起来的,臃肿而冗长,而且往往由一个人负责开发和维护。随着业务的发展和需求变化,本地代码在不断的迭代和变更,最后形成了一个个垂直的功能孤岛,只有原来的开发者才理解接口调用关系和功能需求,一旦原有的开发者离职或者调到其他项目组,这些功能模块的运维就会变得非常困难:

    华为架构师8年经验谈:从单体架构到微服务的服务化演进之路

    当垂直应用越来越多时,连架构师都无法描述应用间的架构关系,随着业务的发展和功能膨胀,这种架构很容易发生腐化。

    • 测试、部署成本高:业务运行在一个进程中,因此系统中任何程序的改变,都需要对整个系统重新测试并部署

    • 可伸缩性差:水平扩展只能基于整个系统进行扩展,无法针对某一个功能模块按需扩展

    • 可靠性差:某个应用BUG,例如死循环、OOM等,会导致整个进程宕机,影响其它合设的应用

    如何解决传统单体架构面临的挑战?

    解决对策:1、拆分 2、解耦 3、透明 4、独立 5、分层。

    • 拆分:对应用进行水平和垂直拆分,例如商品中心、计费中心、订单中心等。

    • 解耦:通过服务化和订阅、发布机制对应用调用关系解耦,支持服务的自动注册和发现

    • 透明:通过服务注册中心管理服务的发布和消费、调用关系

    • 独立:服务可以独立打包、发布、部署、启停、扩容和升级,核心服务独立集群部署

    • 分层:梳理和抽取核心应用、公共应用,作为独立的服务下沉到核心和公共能力层,逐渐形成稳定的服务中心,使前端应用能更快速的响应多变的市场需求

    二、服务化实践

    服务的订阅发布机制

    它的核心理念是实现服务消费者和服务提供者的解耦,让服务消费者能够像使用本地接口一样消费远端的服务提供者,而不需要关心服务提供者的位置信息,实现透明化调用。

    关键技术点:服务的订阅、发布机制、服务的健康状态检测和高HA。

    华为架构师8年经验谈:从单体架构到微服务的服务化演进之路

    常用的服务注册中心有Zookeeper、ETCD,以及基于数据库的配置中心。

    大家在技术选型的时候,需要根据自己的业务实际情况进行选择。例如超大规模集群,服务实例数超过10W,Zookeeper就会存在性能问题。

    现在开源的分布式配置服务很多,如无特殊需求,建议选择开源方案。

    服务化实践-零侵入

    实际上,完全的零侵入很难做到,即使是声明式配置,配置本身也是代码的一部分,只不过相比于代码类库依赖,它不是编译器依赖。

    一种好的做法是,服务的发布和消费通过声明式或者注解的方式,而不是直接调用服务框架的接口,例如Thrift。客户端需要调用Thrift提供的类库访问服务端,这就是代码API级的依赖,对业务代码侵入比较大。

    华为架构师8年经验谈:从单体架构到微服务的服务化演进之路

    一种比较成熟的实践是 利用Spring的扩展机制,通过XML的方式实现服务的发布和消费。

    服务化实践-容错和路由

    单体应用服务化之后,通常采用分布式集群的部署模式。

    这会带来两个问题:

    1. 服务如何路由;

    2. 远端服务访问失败之后,如果进行容错。

    大部分的容错和路由策略可以抽象到分布式服务框架中,通过策略配置的方式提供给用户使用,降低用户的开发成本。

    从业务扩展性角度看,服务框架通常会提供扩展点,供业务做路由和容错定制。例如,业务希望根据手机号码和地市进行路由:

    华为架构师8年经验谈:从单体架构到微服务的服务化演进之路

    服务化实践-本地短路策略

    在电信行业中,小机还是很普遍,应用通常会合设,例如服务提供者和消费者部署到同一台主机上。

    为了提升性能,降低时延,往往会提供本地短路策略,具体策略如下:

    华为架构师8年经验谈:从单体架构到微服务的服务化演进之路

    服务化实践-多样化调用方式

    服务的调用方式,主要有三种:同步服务调用、异步服务调用、并行服务调用。最常用、简单的就是同步服务调用。

    华为架构师8年经验谈:从单体架构到微服务的服务化演进之路

    异步服务调用的工作原理如下:

    华为架构师8年经验谈:从单体架构到微服务的服务化演进之路

    详细步骤如下:

    1. 消费者调用服务端发布的接口,接口调用由分布式服务框架包装成动态代理,发起远程服务调用;

    2. 通信框架异步发送请求消息,如果没有发生I/O异常,返回;

    3. 请求消息发送成功后,I/O线程构造Future对象,设置到RPC上下文中;

    4. 用户线程通过RPC上下文获取Future对象;

    5. 构造Listener对象,将其添加到Future中,用于服务端应答异步回调通知;

    6. 用户线程返回,不阻塞等待应答;

    7. 服务端返回应答消息,通信框架负责反序列化等;

    8. I/O线程将应答设置到Future对象的操作结果中;

    9. Future对象扫描注册的监听器列表,循环调用监听器的operationComplete方法,将结果通知给监听器,监听器获取到结果之后,继续后续业务逻辑的执行,异步服务调用结束。

    并行服务调用,目的是为了提升服务调用的并行度,降低E2E时延。

    华为架构师8年经验谈:从单体架构到微服务的服务化演进之路

    华为架构师8年经验谈:从单体架构到微服务的服务化演进之路

    服务化实践-高性能、低时延

    服务框架的性能,主要强调三个要素:1、I/O通信;2、序列化框架;3、线程调用模型。

    华为架构师8年经验谈:从单体架构到微服务的服务化演进之路

    如果使用Java语言,I/O框架推荐 Netty。

    序列化框架推荐:Thrift、Avro序列化框架、PB等。线程调度模型建议参考Reactor。

    一种线程模型的参考实现方式:Netty的线程模型

    华为架构师8年经验谈:从单体架构到微服务的服务化演进之路

    无锁化串行设计理念

    服务化实践-故障隔离

    故障隔离非常重要,由于经常会采用同步服务调用模式,核心服务和非核心服务共用同一个线程池和消息队列,非核心服务处理慢往往会阻塞核心服务,导致雪崩现象。

    故障隔离的核心技术点如下:

    1. 支持服务部署到不同线程/线程池中

    2. 核心服务和非核心服务隔离部署

    华为架构师8年经验谈:从单体架构到微服务的服务化演进之路

    服务化实践-服务治理

    随着业务规模的不断扩大,小服务资源浪费等问题逐渐显现,需要能够基于服务调用的性能KPI数据进行容量管理,合理分配各个服务的资源占用,提高机器的利用率。

    线上业务发生故障时,需要对故障业务做服务降级、流量控制、流量迁移等,快速恢复业务。

    随着开发团队的不断扩大,服务的上线越来越随意,甚至发生功能相同、服务名不同的服务同时上线。上线容易下线难,为了规范服务的上线和下线,在服务发布前,需要走服务预发布流程,由架构师或者项目经理对需要上线的服务做发布审核,审核通过的才能够上线。

    为了满足服务线下管控、保障线上高效运行,需要有一个统一的服务治理框架对服务进行统一、有效管控,保障服务的高效、健康运行。

    服务治理是分布式服务框架的一个可选特性,尽管从服务开发和运行角度看它不是必须的,但是如果没有服务治理功能,分布式服务框架的服务SLA很难得到保障,服务化也很难真正实施成功。

    从架构上看,分布式服务框架的服务治理分为三层:

    华为架构师8年经验谈:从单体架构到微服务的服务化演进之路

    第1层为服务治理展示层,它主要由服务治理Portal组成,提供可视化的界面,方便服务运维人员进行治理操作。

    第2层为服务治理SDK层,它主要由如下几部分组成:

    1. 服务治理元数据:服务治理元数据主要包括服务治理实体对象,包括服务模型、应用模型、治理组织模型、用户权限模型、数据展示模型等。元数据模型通过Data Mapper和模型扩展,向上层界面屏蔽底层服务框架的数据模型,实现展示层和服务框架的解耦,元数据也可以用于展示界面的定制扩展;

    2. 服务治理接口:服务治理Portal调用服务治理接口,实现服务治理。例如服务降级接口、服务流控接口、服务路由权重调整接口、服务迁移接口等。服务接口与具体的协议无关,它通常基于分布式服务框架自身实现,可以是Restful接口,也可以是内部的私有协议;

    3. 服务治理客户端类库:由于服务治理服务本身通常也是基于分布式服务框架开发,因此服务治理Portal需要集成分布式服务框架的客户端类库,实现服务的自动发现和调用;

    4. 调用示例:客户端SDK需要提供服务治理接口的参数说明、注意事项以及给出常用的调用示例,方便前端开发人员使用;

    5. 集成开发指南:服务治理SDK需要提供集成开发指南,指导使用者如何在开发环境中搭建、集成和使用服务治理SDK。

    第3层为后台服务治理服务层:它通常由一组服务治理服务组成,可以单独部署,也可以与应用合设。考虑到健壮性,通常选择独立集群部署。治理服务的可靠性由分布式服务框架自身来保证,治理服务宕机或者异常,不影响业务的正常使用。服务治理服务通常并不随服务框架发布,治理服务是可选的插件,单独随服务治理框架交付。

    华为架构师8年经验谈:从单体架构到微服务的服务化演进之路

    服务化实践-高可靠性

    关键技术点设计如下:

    1. 服务无状态设计

    2. 服务注册中心集群,宕机不影响业务运行

    3. 服务提供者集群,集群容错屏蔽服务提供者故障

    4. 服务健康状态检测,基于时延等性能KPI指标

    5. 服务治理中心集群,宕机不影响业务运行

    6. 服务级故障隔离

    7. 核心服务独立部署和集群

    8. 跨机房路由和异地容灾

    三、服务化不是银弹

    服务化会带来很多收益,但是它却不是银弹。

    服务化不是银弹-时延问题

    在服务化之前,业务通常都是本地API调用,本地方法调用性能损耗较小。服务化之后,服务提供者和消费者之间采用远程网络通信,增加了额外的性能损耗。

    华为架构师8年经验谈:从单体架构到微服务的服务化演进之路

    服务化不是银弹-问题定位

    在分布式环境下,如何高效的进行问题定界定位和日志检索

    华为架构师8年经验谈:从单体架构到微服务的服务化演进之路

    服务化不是银弹-事务一致性

    服务化、分布式部署之后,有逻辑关联关系的多个数据库操作被打散到集群中各个独立的服务实例中,引入分布式环境下的事务一致性问题。

    华为架构师8年经验谈:从单体架构到微服务的服务化演进之路

    服务化不是银弹-前后台直接通信问题

    前后台直接通信问题如下:

    华为架构师8年经验谈:从单体架构到微服务的服务化演进之路

    存在的问题如下:

    1. 客户端需求和每个微服务暴露的细粒度API不匹配

    2. 微服务使用的RPC私有协议,不是浏览器友好或防火墙友好的

    3. 微服务难以重构。随着时间推移,我们可能想要更改系统划分成服务的方式。如果客户端与微服务直接通信,那么执行这类重构就非常困难了

    服务化不是银弹-团队协作问题

    • 共享服务注册中心问题:为了方便开发测试,经常会在线下共用一个所有服务共享的服务注册中心,这时,一个正在开发中的服务发布到服务注册中心,可能会导致一些消费者不可用。

    • 多团队进度协同问题:服务提供者和消费者相互依赖问题,开发依赖、测试依赖等。


    • 接口前向兼容性问题:由于线上的Bug修复、内部重构和需求变更,服务提供者会经常修改内部实现,包括但不限于:接口参数变化、参数字段变化、业务逻辑变化和数据表结构变化。在实际项目中经常会发生服务提供者修改了接口或者数据结构,但是并没有及时知会到所有消费者,导致服务调用失败

    四、未来演进方向-微服务架构

    华为架构师8年经验谈:从单体架构到微服务的服务化演进之路

    微服务的划分原则是难点,根据华为的经验:微服务划分不是一步到位,而是不断的迭代和演进,最终找到适合自己团队和业务的微服务划分原则。

    华为架构师8年经验谈:从单体架构到微服务的服务化演进之路

    未来演进方向-基于Docker部署微服务

    使用Docker部署微服务的优点总结:

    1. 一致的环境:线上线下环境一致

    2. 避免对特定云基础设施提供商的依赖

    3. 降低运维团队负担

    4. 高性能:接近裸机的性能

    5. 多租户

    华为架构师8年经验谈:从单体架构到微服务的服务化演进之路

    未来演进方向-云端微服务

    利用云平台的弹性资源调度,动态性等,可以实现微服务的Dev&Ops

    华为架构师8年经验谈:从单体架构到微服务的服务化演进之路

    最后我们一起回顾下服务化的演进历程:

    华为架构师8年经验谈:从单体架构到微服务的服务化演进之路

    Q&A

    Q1:上面提到服务化缺点的第三条接口变更问题,请问微服务是如何解决这个问题的呢?或者说微服务相比之下什么优势会避免这个问题?

    A1:根据我们团队的经验,主要从如下几个方面降低影响:1、微服务的接口就是契约,制定 接口兼容性规范;涉及到技术和管理两个层面;2、微服务鼓励只做一件事情,因此它更加稳定;3、基于消费者契约测试,快速发现兼容性问题。

    Q2:微服务架构里,分布式事务如何做的,对数据一致性要求较高的系统是否适合拆分成微服务,或者说微服务的粒度如何把握?

    A2:分布式事务是难点,策略如下:1)如果业务上能够承受非强一致性,建议通过事务补偿的方式做最终一致性,可以基于MQ等中间件来实现;2)如果是转账、实时计费、充值等对实时性要求高的,往往选择强一致性事务,就需要引入TCC等分布式事务框架。无论如何,只要做分布式,事务一致性就会成为问题,跟是否是微服务没必然关系。

    Q3:生产环境中的服务注册中心必然是共享的,那如何去做灰度发布或者A/B Test呢?

    A3:一种比较好的服务灰度策略是:1)服务框架提供灰度规则框架,包括后台引擎和前台Portal,由业务配置灰度规则;2)分布式服务框架支持灰度规则推送和业务自定义路由;3)前端SLB ,例如Ngix做灰度插件,接收灰度规则。消息从前端门户接入到后端服务路由,都支持基于规则的路由分发策略,实现灰度发布。

    Q4:Netty的无锁化串行会比有锁的并行性能更高吗?有案例吗?华为现在都是用Docker部署应用吗?

    A4:Netty的无锁化串行性能问题:1)在实际项目中,线程池争用模式和串行模式我们都使用过,Netty的无锁化串行模式性能更高。Docker部署应用:华为的公有云和私有云都支持基于Docker部署应用,由客户根据需要自主选择。

    Q5:IO通信是怎么保证每次连接成功的呢?

    A5:NIO通信本身并不保证每次连接都成功,它的连接是异步的,你可以根据如下两种策略获得异步链接的结果:1)发起连接之后主动调用同步方法等待结果返回,阻塞式;2)获取异步连接Future,添加Listener监听器监听连接结果,这种模式是异步回调,不会阻塞当前线程。

    Q6:使用zk作为服务注册中心,对与某个服务当客户端连接数很多时候节点变化会引起羊群效应,怎么处理这种问题呢?或者说如何避免这种问题呢?

    A6:这个问题真是好!通常而言,大家会使用服务注册中心做服务可用性检测,如果发现某个服务节点不可用,就会将其从注册中心中删除。但是,有一种场景是ZK检测的结果跟客户端和服务端实际的连接状态不一致。从ZK看,服务提供者可以使用。但是由于服务消费者跟提供者之间的链路已经中断,跟ZK的链路却是正常,这种情况下就会出现状态不一致问题。所以,只依靠ZK做状态检测还不够,需要服务提供者和消费者的链路层做双向心跳检测。

    Q7:我现在做的系统是zk做注册中心服务把地址注册上去(临时节点),客户端拿地址请求,http的,现在发现如果是公网调用的话,对公网资源要求还挺多的,zk公网, 应用公网;为了减少对公网需求,中间加一层nginx,把nx地址注册上去,不过又得加个http探测监控程序,异常还得删掉注册数据,不知道这种做法是否妥当?

    A7:Ng监听ZK注册的服务提供者URL即可,问题不大。

    Q8:用Netty做同通信框架,监控上报应该怎么设计更完善?

    A8:建议的方式如下:Netty自身不用告警,监听Netty的异常事件,然后通过MQ吐出去,监控系统订阅通信框架的事件主题,实现通信框架和监控系统解耦。

    Q9:SOA和微服务架构的区别和联系是?看起来好像啊!

    A9:1) 服务拆分粒度:SOA首先要解决的是异构应用的服务化;微服务强调的是服务拆分尽可能小,最好是独立的原子服务;

    2) 服务依赖:传统的SOA服务,由于需要重用已有的资产,存在大量的服务间依赖;微服务的设计理念是服务自治、功能单一独立,避免依赖其它服务产生耦合,耦合会带来更高的复杂度;

    3) 服务规模:传统SOA服务粒度比较大,多数会采用将多个服务合并打成war包的方案,因此服务实例数比较有限;微服务强调尽可能拆分,同时很多服务会独立部署,这将导致服务规模急剧膨胀,对服务治理和运维带来新的挑战;

    4) 架构差异:微服务化之后,服务数量的激增会引起架构质量属性的变化,例如企业集成总线ESB(实总线)逐渐被P2P的虚拟总线替换;为了保证高性能、低时延,需要高性能的分布式服务框架保证微服务架构的实施;

    5) 服务治理:传统基于SOA Governance的静态治理转型为服务运行态微治理、实时生效;

    6) 敏捷交付:服务由小研发团队负责微服务设计、开发、测试、部署、线上治理、灰度发布和下线,运维整个生命周期支撑,实现真正的DevOps。

    总结:量变引起质变,这就是微服务架构和SOA 服务化架构的最大差异。

    Q10:如果要将现有单机服务重构到微服务,应该考虑哪些问题?数据迁移的安全问题怎么解决?有什么实践方案吗?

    A10:需要考虑的问题如下:1)当前单机应用是否能够满足业务发展需要,有没有必要做服务化改造和分布式部署;2)评估迁移的工作量,以及人员技能培训等。3)自研服务框架还是使用开源的方案。

    数据迁移安全问题:如果内网,通常不会涉及到复杂的安全控制问题;如果跨公网,建议加入API Gateway统一做安全管控。

    实践方案:公开的资料,可以参考淘宝的服务化实践、京东的服务化实践等。其实华为也有,不过遗憾的是目前政策不允许公开出来。

    Q11:麻烦李老师介绍下你们华为内部基于netty做socke通信的协议设计的最佳实践。

    A11:这个问题很大,简单介绍下思路。在11年和13年的时候我分别主持设计了华为基于Mina和Netty的统一NIO通信框架。设计要点如下:1)要熟悉Netty的线程调度模型、常用的类库等,能够熟练使用Netty;2)NIO通信框架的分层原则,哪些该做、哪些不该做,需要识别出来;3)扩展点,预留足够的扩展点给上层应用协议栈做扩展;4)可以内置配置化的安全策略、握手认证、心跳检测等机制;5)可服务性设计,包括日志、性能KPI指标等。

    作者介绍 李林锋

    • 从事华为软件PaaS平台的架构设计和开发工作,8年多NIO、平台中间件领域设计、开发和运维经验,精通NIO通信框架、分布式服务框架、PaaS平台等;

    • 参与设计和开发某网关平台;

    • 曾获得公司总裁技术创新奖;

    • 《分布式服务框架原理与实践》作者。

    好书相送

    在本文评论区留下足以引起共鸣的真知灼见,并在本文发布后24小时之内成为点赞数最多的前2名,即可获得李林锋老师所著的书籍一本哦~

    华为架构师8年经验谈:从单体架构到微服务的服务化演进之路

    特别鸣谢博文视点(www.broadview.com.cn)为本次活动提供图书赞助。

    近期热文(点击标题可阅读全文)

    • 《迄今最安全的MySQL?细数5.7那些惊艳与鸡肋的新特性(上)》

    • 《【DBA+直聘】拥抱理想,抓住机遇,再给自己一个毕业季!》

    • 《高并发系统之限流特技:有了它,京东6.18如虎添翼!》

    • 《MySQL架构优化实战系列2:主从复制同步与查询性能调优》

    • 《当规模到亿级,MySQL是一个更好的NoSQL!》

    • 《回归架构本真:从规划、思维到设计,构建坚不可摧的架构根基》

    • 《手把手教你玩转Git分布式版本控制系统!》

    • 《搜狐畅游高级DBA:Oracle运维中的实战经验和应对技巧》

    展开全文
  • Android基础之架构

    万次阅读 2015-08-20 14:42:21
    我们对android有了个大致的了解,...我开篇就说了,这个系列适合0基础的人且我也是0开始按照这个步骤来学的,谈架构是不是有点螳臂挡车,自不量力呢?我觉得其实不然,如果一开始就对整个android的架构了然于胸,就不

    我们对android有了个大致的了解,知道如何搭建android的环境及简单地写一个HelloWorld程序,而且知道一个android项目包括哪些文件夹和文件及相应的作用。本篇将站在顶级的高度——架构,来看android。我开篇就说了,这个系列适合0基础的人且我也是从0开始按照这个步骤来学的,谈架构是不是有点螳臂挡车,自不量力呢?我觉得其实不然,如果一开始就对整个android的架构了然于胸,就不会误入歧途,能够很好地把握全局。本文的主题如下:

    1、架构图直观
    2、架构详解
    2.1、Linux Kernel
    2.1、Android Runtime
    2.3、Libraries
    2.4、Application Framework
    2.5、Applications
    3、总结
    1、架构图直观

    下面这张图展示了Android系统的主要组成部分:

    这里写图片描述

    图1、Android系统架构(来源于:android sdk)

    可以很明显看出,Android系统架构由5部分组成,分别是:Linux Kernel、Android Runtime、Libraries、Application Framework、Applications。第二部分将详细介绍这5个部分。

    2、架构详解

    现在我们拿起手术刀来剖析各个部分。其实这部分SDK文档已经帮我们做得很好了,我们要做的就是拿来主义,然后再加上自己理解。下面自底向上分析各层。

    2.1、Linux Kernel

    Android基于Linux 2.6提供核心系统服务,例如:安全、内存管理、进程管理、网络堆栈、驱动模型。Linux Kernel也作为硬件和软件之间的抽象层,它隐藏具体硬件细节而为上层提供统一的服务。

    如果你学过计算机网络知道OSI/RM,就会知道分层的好处就是使用下层提供的服务而为上层提供统一的服务,屏蔽本层及以下层的差异,当本层及以下层发生了变化不会影响到上层。也就是说各层各司其职,各层提供固定的SAP(Service Access Point),专业点可以说是高内聚、低耦合。

    如果你只是做应用开发,就不需要深入了解Linux Kernel层。

    2.2、Android Runtime

    Android包含一个核心库的集合,提供大部分在Java编程语言核心类库中可用的功能。每一个Android应用程序是Dalvik虚拟机中的实例,运行在他们自己的进程中。Dalvik虚拟机设计成,在一个设备可以高效地运行多个虚拟机。Dalvik虚拟机可执行文件格式是.dex,dex格式是专为Dalvik设计的一种压缩格式,适合内存和处理器速度有限的系统。

    大多数虚拟机包括JVM都是基于栈的,而Dalvik虚拟机则是基于寄存器的。两种架构各有优劣,一般而言,基于栈的机器需要更多指令,而基于寄存器的机器指令更大。dx 是一套工具,可以將 Java .class 转换成 .dex 格式。一个dex文件通常会有多个.class。由于dex有時必须进行最佳化,会使文件大小增加1-4倍,以ODEX结尾。

    Dalvik虚拟机依赖于Linux 内核提供基本功能,如线程和底层内存管理。

    2.3、Libraries

    Android包含一个C/C++库的集合,供Android系统的各个组件使用。这些功能通过Android的应用程序框架(application framework)暴露给开发者。下面列出一些核心库:

    系统C库——标准C系统库(libc)的BSD衍生,调整为基于嵌入式Linux设备
    媒体库——基于PacketVideo的OpenCORE。这些库支持播放和录制许多流行的音频和视频格式,以及静态图像文件,包括MPEG4、 H.264、 MP3、 AAC、 AMR、JPG、 PNG
    界面管理——管理访问显示子系统和无缝组合多个应用程序的二维和三维图形层
    LibWebCore——新式的Web浏览器引擎,驱动Android 浏览器和内嵌的web视图
    SGL——基本的2D图形引擎
    3D库——基于OpenGL ES 1.0 APIs的实现。库使用硬件3D加速或包含高度优化的3D软件光栅
    FreeType ——位图和矢量字体渲染
    SQLite ——所有应用程序都可以使用的强大而轻量级的关系数据库引擎
    2.4、Application Framework

    通过提供开放的开发平台,Android使开发者能够编制极其丰富和新颖的应用程序。开发者可以自由地利用设备硬件优势、访问位置信息、运行后台服务、设置闹钟、向状态栏添加通知等等,很多很多。

    开发者可以完全使用核心应用程序所使用的框架APIs。应用程序的体系结构旨在简化组件的重用,任何应用程序都能发布他的功能且任何其他应用程序可以使用这些功能(需要服从框架执行的安全限制)。这一机制允许用户替换组件。

    所有的应用程序其实是一组服务和系统,包括:

    视图(View)——丰富的、可扩展的视图集合,可用于构建一个应用程序。包括包括列表、网格、文本框、按钮,甚至是内嵌的网页浏览器
    内容提供者(Content Providers)——使应用程序能访问其他应用程序(如通讯录)的数据,或共享自己的数据
    资源管理器(Resource Manager)——提供访问非代码资源,如本地化字符串、图形和布局文件
    通知管理器(Notification Manager)——使所有的应用程序能够在状态栏显示自定义警告
    活动管理器(Activity Manager)——管理应用程序生命周期,提供通用的导航回退功能
    2.5、Applications

    Android装配一个核心应用程序集合,包括电子邮件客户端、SMS程序、日历、地图、浏览器、联系人和其他设置。所有应用程序都是用Java编程语言写的。更加丰富的应用程序有待我们去开发!

    3、总结

    从上面我们知道Android的架构是分层的,非常清晰,分工很明确。Android本身是一套软件堆叠(Software Stack),或称为「软件叠层架构」,叠层主要分成三层:操作系统、中间件、应用程序。从上面我们也看到了开源的力量,一个个熟悉的开源软件在这里贡献了自己的一份力量。

    现在我们对android的系统架构有了一个整体上的了解,我将用一个例子来深入体会一下,但是考虑到此系列希望0基础的人也能看懂,在介绍例子之前将介绍一下Android应用程序的原理及一些术语,可能需要几篇来介绍。敬请关注!

    展开全文
  • 物联网体系结构之架构

    千次阅读 2018-10-08 21:55:58
    物联网三层体系结构为基础,重新对物联网体系结构提出架构。三层体系结构并不能完全的体现物联网的功能,并且也限制了物联网在某些产品研发的方面的所能发挥的作用。在已经被列为物联网技术的基础重新划入了...

    从物联网三层体系结构为基础,重新对物联网体系结构提出四层架构。三层体系结构并不能完全的体现物联网的功能,并且也限制了物联网在某些产品研发的方面的所能发挥的作用。在已经被列为物联网技术的基础上重新划入了新的技术,并说明了新加入的技术与物联网的关系以及对物联网应用的好处。给出了自己对学习物联网的建议。

    关键词 :物联网技术;四层架构 ;嵌入式技术;第五代移动通信技术;大数据

    在经济科技高速发展的当今社会,物联网的兴起似乎已经成了必然的趋势。各高等教育机构纷纷开展物联网课程,社会人才也在不断地向物联网行业靠拢,国家扶持物联网发展的文件不断下发。但是人们的生活似乎到现在还没有什么实际的改变,甚至许多人连物联网是什么都不知道也有甚者物联网专业的学生也清楚。这只能说明,我国的物联网发展正处在暗流涌动之中。在等待某一天的到来。

    现今,大多数人的认为是对物联网分为三个层次,分别是感知层、传输层、应用层。感知层从环境中识别物体、感知数据信息,传输层将信息从感知层中取出传输到服务器,应用层进行汇总、提取、分析、总结。从三层体系结构上分析,似乎物联网的应用也不是特别的广泛。人们似乎也并不是特别需要这样的物联网。但是这三层物联网体系结构并不能包含物联网所有的体系结构,这只是物联网中万中有一的体系。

    万物互联,即为物联网。世界上千千万万的实物,实物的形态以及表现形式都是不尽相同。物联网应用的涉及范围很容易被三层体系结构所误导。感知层就只是感知数据、识别物体;传输层就是指传输数据;应用层就是将传输层传来的数据进行加工处理以实现智能化的应用。这只是对某些领域是如此。对于深入人们生活的领域。应该另外进行分层。

    第一层:对事物的识别、信息的采集、终端设备的信息收集以及所有能 够产生能被人们收集利用的信息的收集、从第四层返回的结果,做出相应操 作。
    第二层:对收集的信息进行有效的传输,确保数据传输的质量、速度、 重要性。
    第三层:对数据的收集、分析、提取、再分析。能够被有效利用的信息 进行利用、存储(备用分析)。
    第四层:处理结果、相应操作的返回。

    四层之间关系结构如下图。

    在这里插入图片描述

    支持物联网发展的并不是什么特殊的高新技术,从现阶段来看,只是在原有的技术的基础上的应用和拓展。

    物物相连,我们需要收集数据。也就需要了许多的传感设备。在感知世界信息的同时,需要对信息进行简单的处理,让这些信息变成对我们有用的信息。这个过程不如说就是嵌入式设备的发展。

    嵌入式技术是执行专用功能并被内部计算机控制的设备或者系统。嵌入式能够连接微控制器和开关、按钮、传感器、模数转化器、控制器、LED(发光二极管)和显示器的I/O端口等。并且可裁剪性强,可以根据实际情况进行特殊的定制。嵌入式设备不仅能够满足信息的收集的各项需求,而且还能通过预留端口(嵌入式设备一般都是统一接口)对将来可能需要的设备进行添加升级。嵌入式设备也能对第四层返回的信息进行相应操作。同时,嵌入式系统具有便利灵活、性能价格比高、嵌入性强等特点,可以嵌入到现有任何信息家电、智能设备以及工业控制系统中。嵌入式技术是物联网技术的必要选择。但是嵌入式技术并不是物联网技术。

    世间万物,都需要感知层去感知信息并汇总信息上传。无数的传感器所汇集的信息会如洪流一般。若没有稳定快速的网络传输协议,难以支持。再加上许多还未出现或普及的移动智能设备,对网络传输速度、实时性、稳定性、带宽有一定的要求。5G的出现可以在一定的程度上解决这些问题(到底会解决成什么样,还要看实际的普及商用之后才知道)。

    5G是第五代移动通信网络。从移动通讯技术的发展就可以看出5G的普遍商用将会给世界带来翻天覆地的变化。第一代移动通信技术(1G)是指最初的模拟、仅限语音的蜂窝电话标准。第二代移动通信系统是以数字技术为主体的移动经营网络。与第一代模拟蜂窝移动通信相比,第二代移动通信系统提供了更高的网络容量,改善了话音质量和保密性它克服了模拟移动通信系统的弱点,话音质量、保密性能得到大的提高。由于第二代数字移动通信系统带宽有限,限制了数据业务的应用,也无法实现高速率的业务如移动的多媒体业务。在第三代互联网时代,用户可以随时、随地、随意地通过互联网获得需要的信息服务。它支持高速数据传输的蜂窝移动通讯技术,能够同时传送声音及数据信息,速率一般在几百kbps以上。3G与2G的主要区别是在传输声音和数据的速度上的提升,它能够在全球范围内更好地实现无线漫游,并处理图像、音乐、视频流等多种媒体形式,提供包括网页浏览、电话会议、电子商务等多种信息服务,同时也要考虑与已有第二代系统的良好兼容性。第四代移动通信技术(4G)是集3G与WLAN于一体,并能够快速传输数据、高质量、音频、视频和图像等。4G能够以100Mbps以上的速度下载,比目前的家用宽带ADSL(4兆)快25倍,并能够满足几乎所有用户对于无线服务的要求。5G作为第五代移动通信技术,其峰值理论传输速度可达每秒数10GB,这比4G网络的传输速度快数百倍,整部超高画质电影可在1秒之内下载完成。爱立信宣布,在5G无线技术一项无线测试中,传输速度峰值达到了5Gbps。无线传输速度达到5Gbps,比LTE连接标准快了250倍,标志着无线传输速度再创新纪录。这一传输速度,无论对于智能手机,还是汽车、医疗和其他设备而言,均将受益于此。网络达到5Gbps速度,下载一部50GB的电影仅需80秒钟,而这一速度为谷歌光纤1Gbps传输速度的5倍。

    虽数据还只是实验室的数据,但是相信到实际的应用中,应该也不会差多少。5G到目前为止,还没有开展明显的大规模商用。如果大规模商用后,实际的应用不是特别的理想。那么,物联网的发展和等待5G的商家、企业恐怕会受到一个巨大的打击。但是瓶颈总会被突破的,只是时间问题。

    随着技术的进步、社会的进步,各种数据的传输量会随之增大。物联网的需求也会不断地增加,作为最基本的网络传输也会得到发展。这是一种趋势。
    对最基本的数据高速处理,进行分析、整合、提取,得到对我们有用的信息。这需要大数据的支持。

    物联网所产生的数据十分庞大。已经超出了普通家用电脑所能够处理的范围。再加上某些处在第一层的智能设备由于系统资源有限、内核小、处理能力有限,某些功能没有办法实现。所以第一层需要将急需处理的信息通过快速安全稳定有效的网络将信息传到第三层。通过第三层的快速处理,将返回的结果再次通过网络传回第一层。一个设备的数据量不大,但是成千万上亿的设备产生的数据。如果没有大数据的处理能力,那么很多的构想都是空想。

    物联网的发展需要各方面人才的共同努力。光靠高等教育培育的物联网人才,难以肩负起物联网的发展。他们只能给物联网的发展提供一个大致的框架、对物联网产品的研发提供思路、熟练物联网研发步骤。若细分到构建每个模块,现存的物联网人才没有一个能够担任的。物联网就像一个大家庭,它的成员有嵌入式技术、网络通信技术、大数据技术以及许多底层、上层应用技术。

    作为物联网专业的学生,我自己称能够学通学精中间的一门技术,都是特别厉害的了。能够熟练掌握并运用各种技术的人,那是神一样的存在。论技术,我们物联网专业的学生不及别的专业专攻一门技术的人才,但是我们的优势就是什么技术自己都懂点(要我们用做个东西,那恐怕是不存在),对物联网的体系结构,如何构建框架,研发一个物联网产品我们该如何去做的步骤,我们还是比较清楚的。所以对物联网专业的学生,我自己建议在学好各类框架、各类应用基础技术的的基础上,自己专攻一门自己感兴趣的技术。这样不仅能够让自己技术更加的贴合时代的发展,对自己的个人发展也会有很好的用处。

    相关技术解说来源百度百科。

    展开全文
  • 在理解了种通信模型的工作特点和区别后,对于我们后文介绍搭建在其的各种通信框架,集成思想都是有益的。 目前常用的IO通信模型包括种(这里说的都是网络IO):阻塞式同步IO、非阻塞式同步IO、多路复用IO、和...
  • 本篇文章开始,我们将花一到两篇的篇幅介绍ESB(企业服务总线)技术的基本概念,为读者们理清多和ESB技术有关名词。我们还将在其中为读者阐述什么情况下应该使用ESB技术。接下来,为了加深读者对ESB技术的直观...
  • 软件架构学习小结

    千次阅读 2015-12-22 15:46:22
    软件架构设计系统整体架构需求到设计的每细节都要考虑到,把握整个项目,使设计的项目尽量效率高,开发容易,维护方便,升级简单。本文从架构师职责、软件架构定义、设计架构、评估架构架构管理等方面来描述...
  • Kubernetes集群搭建详细过程前言搭建步骤一、各节点基础配置二、制作CA证书三、配置etcd、在master节点配置Kubernetes API服务五、在master节点部署Controller Manager服务、Kubernetes Scheduler六、在master...
  • 本篇文章一共分为四个部分,分别是开放生态、开放网关、开放授权和开放安全。为什么要做开放,开放的技术实现有哪些,主要是开放网关和授权,同时我们开放了以后肯定还需要安全,需要开放的安全保障。 1、开放生态 ...
  • 阿里架构总监一次讲透中台架构

    千次阅读 2019-08-27 10:31:14
    架构总监谢良纯,中间件技术专家 玄难等几位大牛,关于中台架构的几次分享内容,将业务中台形态、中台全局架构、业务中台化、中台架构图、中台建设方法论、中台组织架构、企业中台建设实施步骤等总共13页PPT精华的...
  • 零开始搭建的意思,就是需求分析,系统规划,设计分析和落地实践几个步骤无到有的过程。考虑左右,为了个人学习和提升,选型基于流行的springboot+springcloud,零开始搭建一套自己用于学习的研发平台。 ...
  • 最流行的Spring Cloud微服务架构实践与经验总结

    万次阅读 多人点赞 2017-11-09 10:40:10
    当应用的不同组件在扩展需求存在差异时,微服务架构便体现出其灵活性,因为每服务可以根据实际需求独立进行扩展。 什么是Spring Boot Spring Boot是由Pivotal团队提供的全新框架,其设计目的是...
  • 架构师职责

    千次阅读 2012-06-11 10:27:58
    然后在平台支持之做技术相关架构设计(主要会采用面向对象OO,面向方面编程AOP以及面向服务架构设计SOA等思想),在SOA推广IBM和SUN两家公司尤为突出;在业务不断的变化中、架构的更新中,找到变化中不变的东西
  • 企业IT架构的发展历程

    千次阅读 多人点赞 2019-04-17 09:58:52
    提起IT架构人都不陌生,有人说IT架构是企业架构中的一部分,与业务架构结合,为企业打造适合业务的IT信息化建设,也有人说IT架构是方法论,是一种为企业制定IT构建策略、标准、服务、产品、解决方案及对应IT厂商...
  • 基于 JavaScript 语言的快速物联网开发架构

    万次阅读 多人点赞 2017-06-30 09:50:58
    而物联网架构则稍微麻烦了一些,多了一个层级,便多了一个步骤。 硬件层的微控制器通过直连的方式,采集各式各样的数据,比如温度、湿度等。而受限于微控制器的成本、环境条件等因素,它可能无法直接连接到...
  • Android Display架构分析(

    千次阅读 2013-03-14 14:49:04
    参考: Android display架构分析二-SW...Android display架构分析-msm_fb.c 函数和数据结构介绍。。。。。 高通Android平台下关于display部分的几关键问题 高通Qc FB驱动 以及 LCD调试过程 And
  • 高通Android display架构分析

    千次阅读 2015-06-27 17:07:00
    Kernel Space Display架构介绍函数和数据结构介绍函数和数据结构介绍函数和数据结构介绍数据分析初始化过程分析User Space display接口Kernel display接口典型应用flow分析介绍 Surface manager(surface ...
  • 放弃Dubbo,选择最流行的Spring Cloud微服务架构实践与经验总结Spring Cloud 在国内中小型公司能用起来吗? 2016 年初一直到现在,我们在这条路上已经走了一年多。作者:张强来源:51CTO技术栈|2017-10-19 09:16...
  • 云原生落地实践的25个步骤

    千次阅读 2020-06-01 08:13:30
    其实我们在很多的技术大会,看到的都是分层架构图,就像一节我们分的六层次一样,这容易给希望落地云原生的企业造成误解,因为大部分公司的云原生体系的建设都不是按层次来建设的,不会IaaS完全建设完毕,再...
  • 分布式架构知识体系

    万次阅读 2019-02-15 09:04:01
    从而对SOA到MSA进化有立体的认识,概念和工具应用更近一步了解微服务分布式的本质,身临其境的感受如何搭建全套微服务架构的过程。 4.基础理论 4.1SOA到MSA的进化 SOA面向服务架构 由于业务发展到一定层度后...
  • 某工业企业公共服务平台架构设计

    千次阅读 2011-01-26 14:51:00
    最近参与到的一大的工业企业系统的架构设计,思路整理的过程记录下来
  • 文/技术领导力社区编辑/Emma本文整理了阿里几位技术专家,如架构总监谢纯良,中间件技术专家 玄难等几位大牛,关于中台架构的几次分享内容,将业务中台形态、中台全局架构、...
  • “第三天”的性能测试一节中,我们得知了决定性能测试的几重要指标,它们是: ü 吞吐量 ü Responsetime ü Cpuload ü MemoryUsage 我们也在第三天的学习中对Apache做过了一定的优化,使其...
  • 软件架构学习

    千次阅读 2014-05-10 17:37:00
    软件架构设计系统整体架构需求到设计的每细节都要考虑到,把握整个项目,使设计的项目尽量效率高,开发容易,维护方便,升级简单。本文从架构师职责、软件架构定义、设计架构、评估架构架构管理等方面来描述...
  • 文章目录架构设计请列举出在JDK中几常用的设计模式?什么是设计模式?你是否在你的代码里面使用过任何设计模式?静态代理、JDK动态代理以及CGLIB动态代理静态代理动态代理cglib代理单例模式工厂模式观察者模式装饰...
  • 本文来自携程技术中心基础业务研发部的《应用架构涅槃》系列分享。据基础业务研发部负责人李小林介绍,互联网二次革命的移动互联网时代,如何吸引用户、留住用户并深入挖掘用户价值,在激烈的竞争中脱颖而出,是各大...
  • 架构设计的本质

    千次阅读 2020-10-12 15:45:24
    简介:实际上架构只是系统设计里面的一重要环节,除了架构还包含了商业诉求,业务建模,系统分析,系统设计等重要领域。本文尝试更高视角重新审视架构设计的工作,把架构设计的上升到系统设计的立体空间去探索,...
  • 网站架构资料收集整理

    千次阅读 2013-01-31 16:27:19
    1.系统概况图图1.1 系统架构概况图图1.2 较为完整的系统架构图2.系统使用的主要技术下列排名不分先后2.1前端JavaScript,html,css,silverlight,flashJqueryJavascript类库,用来简化html的操作,事件处理,动画,...
  • 本文ODPS面临的挑战、技术架构、Hadoop迁移到ODPS、应用实践注意点等方面带领我们初步了解了ODPS的现状与前景。 初识ODPS ODPS是分布式的海量数据处理平台,提供了丰富的数据处理功能和灵活的编程框架,主要...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 25,015
精华内容 10,006
关键字:

信息流从底层架构上的四个步骤