不要因为走得太远而忘记为什么出发:陈虻,我们听你讲

不要因为走得太远而忘记为什么出发:陈虻,我们听你讲

加载中...

微信扫码,免登录解锁高速下载

如何使用 & 隐私说明

精彩点评

  • 不要因为走得太远而忘记为什么出发:陈虻,我们听你讲
    BGM
    推荐

    本来以为这种类型的书会长篇大论都是理论知识,相当晦涩,谁知截至目前我所读到的部分,实在是太契合实际使用中的业务需求。原本也是带着功利性来看这本书,但是发现不光是技术层面的洗礼,对于整个服务架构思路有全面的提高。书虽然还没看完,但是这本书一定是要经常来翻翻,常读常新。

  • 不要因为走得太远而忘记为什么出发:陈虻,我们听你讲
    HD
    推荐

    初看本书像是泛泛而谈,但如果你理解它所说的内容的话会发现都是经验之谈。别人有用的经验其实比知识本身要珍贵

  • 不要因为走得太远而忘记为什么出发:陈虻,我们听你讲
    小佳
    推荐

    这本书cool哦!介绍的微服务框架,整理如下以供参考: 1.服务注册中心service register,比如,zookeeper。 springcloud, netflix,Eureka。 2.服务调用方式, RPC, rest API。服务间通过REST api相互通信。 3.服务网关。gateway,负责分发路由,负载均衡策略,鉴权等。客户端不会直接request服务端,要经过网关层! 4.断路器。很主要,类似熔断机制。 5.分布式配置config。 6.服务追踪,也是链路追踪。 7.消息总线bus。 8.数据流cloud stream。 9.批量任务cloud task. 以上不是业务拆分,是微服务框架分布式分层解耦后的架构层级。对于不同业务拆分的规则是尽可能做到最大限度的松耦合。书中有提到模块间的界限划分!但是我还不太理解!他还没有结合具体业务场景相关,进行深入探讨!

  • 不要因为走得太远而忘记为什么出发:陈虻,我们听你讲
    陈文科
    推荐

    软件的本质困难在于软件本身的复杂性。 我们头脑中最多同时注意5~9件事,因此对付复杂性的方法自然而然就是——分而治之。 数据库,模块化,面向对象,MVC,SOA(Service-Oriented-Architecture,面向服务的架构)都是在做抽象,都是在做分而治之,都有同一个指导纲领: 高内聚,低耦合。它们的主要差别在于实现方式和关注的粒度不同。其核心都是分解复杂度,使得每小块软件的复杂度能被我们完全控制。 微服务架构可以看做是SOA的一种特定方法,它并不是银弹。 它只是通过以一个个微服务的方式,来拆分整个软件的复杂度,各个微服务间通过清晰可控的信息交流,来完成整个软件的功能。 但是,服务分离后,所引入的一系列分布式问题,我们仍然无法回避。 但所幸的是,服务分离后,各个服务之间的极致的松耦合使得重用和移植变得非常容易。很容易集成一些第三方的服务,或搭建在不同平台之上(例如:公有云,私有云,混合云,物理集群)。  而且,现在云厂商都在试图提供一整套的微服务解决方案,使得开发人员不需要去解决分布式所引入的种种问题,只需要关注于业务逻辑本身。云厂商帮你解决分布式的一致性,可用性,隔离性,弹性伸缩;为你提供安全保护,通信协议,开发工具,集成测试;提供持续集成,持续交付,灰度发布的能力;提供完善的监控,可选的容灾策略,以及运营数据的查询与显示;还有一系列支持用户自定义的接口,可以方便的定制化以及和其他云服务无缝隙兼容的能力。 因此,我觉得微服务是一个高度软件工程化的,并且和云结合到一起才能落地的产物。而微服务的一种极致形式就是无服务器函数,真的只需要开发人员关注服务本身。

  • 不要因为走得太远而忘记为什么出发:陈虻,我们听你讲
    季称利(纯阳子)
    推荐

    (公众号:纯阳书评/微信号:chimbusco88)一千个人眼中就会有一千个哈姆雷特,这句话可能大家都很熟悉,那么我要问一个问题,这一千个哈姆雷特到底有没有高地上下之分呢?我的答案是有的,而且我相信大家也会同意这一点,尽管评判角度不同,高地上下的具体结果也不同。微服务同样也是这个道理,尽管微服务是一个软件开发中的技术问题,相对于文学作品中的人物,显得确定性更大一些,但是这种确定性还是没有大到可以让人们在这个问题上达成绝对共识,更何况微服务这种技术思想本身和它的具体技术实现都处于流变之中,不断演进不断变化,所以这种共识本身也处于不断演进之中。因为共识不可得,所以共识就不再重要,真正重要的反而是关于问题的高见,而本书显然就是关于微服务的一种高见或者是高见的组合。 之所以本书在微服务问题上有见地,在与本书能够从系统论或者是从一种应用构建整体环境的角度看待微服务,超越了一般观点只是停留在软件开发、软件架构这个层次上谈微服务。具体来讲有以下几个超越,第一个是超越了技术,从业务技术一体化的角度谈微服务。就想传统SOA时代一样,一般观点总是在反复强调软件要高内聚、低耦合,实现软件服务化,服务提供者要隐藏实现细节,只暴露契约接口,做到独立自主,其修改和调整不影响消费者。但是以上这些只是目标和原则的混合,更多的是技术上的追求,但是更重要的问题是我们怎样划分服务领域,依据是什么,功能还是业务,服务领域到底是多大为好,好的依据和评判标准又是什么?作者在这些问题上提出了自己的经验和洞见,也只有在这些问题上有了清晰的思路,业务问题和微服务技术才有了真正的桥梁,否则只会出现站在技术上望业务,得到似是而非的解决方案。二是超越了软件开发本身。微服务本身是软件架构和开发技术,但是这种技术需要一个配套的支撑环境来支持才可以真正发挥它的作用和价值,体现这种架构的优势,如果只及一点不及其余,只关注微服务的技术实现这个环节的事情,不考虑操作系统、硬件、虚拟化等方面技术和资源的综合考虑和配套,微服务的价值也不可很好的体现。作者在这方面的贡献就是综合考虑了操作系统的虚拟化、容器化、微服务配套的CD和CI、微服务环境下的安全、规模化和系统扩展问题,基于开阔的视野、丰富的经验,提供了一套系统的微服务思维模板。尽管单独拿出其中某一块来感觉都不是特别详实,略感单薄,但是作为整体来讲覆盖全面,对于项目中涉及微服务的人事来讲是一本快速发现并扫除盲点的好书, 也就是说可能本书不能告诉你所有的知识,但是可以第一时间告诉你应该考虑和关注哪些问题。也就是说这本书会提醒你考虑什么、怎么思考才是对的。

Copyright © 2020 - 2022 Mitsuha. All Rights Reserved. 用户协议 · 隐私政策 ·