阿里P7架构讲解:微服务设计

本人免费整理了Java高级资料,涵盖了Java、Redis、MongoDB、MySQL、Zookeeper、Spring Cloud、Dubbo高并发分布式等教程,一共30G,需要自己领取。
传送门:https://mp.weixin.qq.com/s/osB-BOl6W-ZLTSttTkqMPQ

前言

微服务是一种分布式系统解决方案,推动细粒度服务的使用,这些服务协同工作,且每个服务都有自己的生命周期。因为微服务主要围绕业务领域建模,所以避免了由传统的分层架构引发的很多问题。微服务也整合了过去十年来的新概念和技术,因此得以避开许多面向服务的架构中的陷阱。本书包含了业界使用微服务的很多案例,包括Netflix. Amazon. Gill 和REA等。这些组织都发现这种架构有一个很大的好处,就是能够给予他们的团队更多的自治。

谁该读这本书

细粒度的微服务架构包含了很多方面的内容,所以本书的范围很广,适用于对系统的设 计、开发、部署、测试和运维感兴趣的人们。对于那些已经走上更细粒度架构之路的人, 无论是开发新应用,还是拆分现有的单块系统,都会因书里很多的实用建议而受益。对于 想要了解微服务方方面面的人,这本书也可以帮助你确定微服务是否适合你。

当今的微服务

微服务是一个快速发展的主题。尽管它不是-一个新的想法(虽然这个词本身是),但世界 各地的人们所获取的经验以及新技术的出现正在对如何使用它产生深远的影响。因为其变 化的节奏很快,所以这本书更加关注理念,而不是特定技术,因为实现细节变化的速度总 是比它们背后的理念要快得多。而且,我完全相信几年后我们会对微服务适用的场景了解 更多,也会知道如何更好地使用它。
所以,虽然在本书中我已经尽最大的努力来提炼出这个主题的本质,但如果你对这个话题 感兴趣的话,还是要做好进行若干年持续学习的准备,来保证你处在这个领域的前沿!

●第1章,微服务

首先介绍微服务的基本概念,包括微服务的主要优点以及一些缺点。

●第2章, 演化式架构师
这一章讨论了架构师需要做出的权衡,以及在微服务架构下具体有哪些方面是我们需要考虑的。

●第3章,如何建模服务
在这一章我们使用领域驱动设计来定义微服务的边界。

●第4章,集成
这一章开始深入具体的技术,讨论什么样的服务集成技术对我们帮助最大。我们还将深入研究用户界面,以及如何集成遗留产品和COTS (Commercial Of-The -Shelf,现成的商业软件)产品这个主题。

●第5章,分解单块系统
很多人对于如何把一个大的、难以变化的单块系统分解成微服务很感兴趣,而这正是我们将在这一章详细介绍的内容。

●第6章,部署
尽管这本书讲述的主要是微服务的理论,但书中的几个主题还是会受到最新技术的影响,部署就是其中之一,我们在这一章会探讨这方面的内容。

●第7章,测试
本章会深入测试这个主题,测试在部署多个分散的服务时很重要。特别需要注意的是,消费者驱动的契约测试在确保软件质量方面能够起到什么样的作用。

●第8章,监控
在部署到生产环境之前的测试并不能完全保证我们上线后没有问题。这--章探讨了细粒度的系统该如何监控,以及如何应对分布式系统的复杂性。

●第9章,安全
这一章将会研究微服务的安全,考虑如何处理用户对服务及服务间的身份验证和授权。在计算领域,安全是一个非常重要的话题,而且很容易被忽略。尽管我不是安全专家,但我希望这--章至少能帮助你了解在构建系统,尤其是微服务系统时,需要考虑的一些内容。

●第10章,康威定律和系统设计
这一章的重点是组织结构和系统设计的相互作用。许多组织已经意识到,两者不匹配会导致很多问题。我们将试图弄清楚这一困境的真相, 并考虑一些不同的方法将系统设计与你的团队结构相匹配。

●第11章,规模化微服务
这一章我们将开始了解规模化微服务所面临的问题,以便处理在有大量服务时失败概率增大及流量过载的问题。

●第12章,总结
最后一章试图分析微服务与其他架构有什么本质上的不同。我列出了微服务的七个原则,并总结了本书的要点。

原文地址:https://www.cnblogs.com/yunxi520/p/12427985.html

时间: 2024-10-14 01:15:57

阿里P7架构讲解:微服务设计的相关文章

微服务设计关键的难点:微服务架构的数据库是如何设计的?

单独的数据库: 微服务设计的一个关键是数据库设计,基本原则是每个服务都有自己单独的数据库,而且只有微服务本身可以访问这个数据库.它是基于下面三个原因. 优化服务接口:微服务之间的接口越小越好,最好只有服务调用接口(RPC或消息),没有其他接口.如果微服务不能独享自己的数据库,那么数据库也变成了接口的一部分,这大大拓展了接口范围. 错误诊断:生产环境中的错误大部分都是和数据库有关的,要么是数据出了问题,要么是数据库的使用方式出了问题.当你不能完全控制数据库的访问时,会有各种各样的错误发生.它可能是

微服务集成——《微服务设计》读书笔记

一.理想的集成应该是什么样的? 1.避免破坏性修改 如果在一个微服务的响应中添加一个字段,服务的消费方不应该受到影响. 2.保证API的技术无关性 微服务之间的通信应该是与技术无关的. 3.使服务的消费方易于使用 如果消费方使用该服务比登天还难,那么无论该微服务多漂亮都没用任何意义.但同时,易于使用的服务可能内部封装了很多细节,这会增加耦合. 4.隐藏内部实现细节 消费方与服务方的内部细节应该是分开的,如果与细节绑定,则意味着改变服务内部的一些变化,消费方也要跟着修改,这会增加修改的成本. 二.

《微服务设计》读书笔记大纲

cha1:微服务的概念--<微服务设计>读书笔记 cha2:微服务架构师的职责--<微服务设计读书笔记> cha3:建模:确定服务的边界--<微服务设计>读书笔记 cha4:微服务集成--<微服务设计>读书笔记 服务的协作:服务间的消息传递--<微服务设计>读书笔记 cha5:拆分:分解单块系统--<微服务设计>读书笔记 cha6:部署:持续集成(CI)与持续交付(CD)--<微服务设计>读书笔记 cha7:测试--<

单体架构还是微服务架构,这是个问题?

(此文章同时发表在本人微信公众号"dotNET每日精华文章",欢迎右边二维码来关注.) 微服务架构现在越来越流行,那么是不是就意味着单体架构不再成为我们的选择了呢?个人认为这个要依情况而定. 现在谈及微服务架构的文章.演讲随处可见,似乎所有系统的架构都开始尽情拥抱微服务架构,包括笔者前久为一个异构电商平台系统设计的架构也选用了这种风格.然而,我们在选择微服务架构之前,一定要问一句"你现在面对的系统,微服务架构是一个好的选择吗?".当然,这个问题也是我这几天在思考的.

《微服务设计》

最近在看<微服务设计>这本书.记录下自己的心得体会. 豆瓣:https://book.douban.com/subject/26772677/ 1.主题脉络 第一章 微服务:阐述了微服务的特点,以及带来的好处: 第二章 演化式架构师:描述了架构师的工作内容和若干准则,非常有参考价值. 第三章 如何建模服务 :好服务的标准?以及如何拆分服务的方法:上下文边界+业务概念沟通 第四章 集成:分享了服务间的协作方式,以及服务的版本管理 第五章 分解单块系统:更细的阐述拆分服务的方面. 第六章 部署:服

【架构】微服务实战:从发布到架构——上篇

微服务实战:从发布到架构——上篇  MaxLeap2016-03-23 10:42 “微服务”是当前软件架构领域非常热门的词汇,能找到很多关于微服务的定义.准则,以及如何从微服务中获益的文章,在企业的实践中去应用“微服务”的资源却很少.本篇文章中,会介绍微服务架构(Microservices Architecture)的基础概念,以及如何在实践中具体应用. 单体架构(Monolithic Architecture ) 企业级的应用一般都会面临各种各样的业务需求,而常见的方式是把大量功能堆积到同一

安全——《微服务设计》读书笔记

身份认证和授权       1.单点登录(SSO) 当主体试图访问一个资源,他会被定向到一个身份提供者那里进行身份验证,身份提供者验明正向后会发消息给服务提供者,让服务提供者来决定是否允许它访问资源. SAML和OpenID Connect/OAuth2.0是企业领域中占据统治地位的单点解决方案.       2.单点登录网关 现在问题来了,多个微服务是不是也要单独地与单点登录系统交互,显然这样是不合理的,这意味着大量的重复工作.我们可以使用单点登录网关来帮助我们完成这一工作,在使用者通过单点登

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

华为架构师8年经验谈:从单体架构到微服务的服务化演进之路 目录技术文章2016年6月28日 转自:http://www.58maisui.com/2016/06/28/a-327/?ref=myread 本次分享的大纲如下: 传统应用开发面临的挑战 服务化实践 服务化不是银弹 服务化架构的演进方向 一 .传统应用开发面临的挑战 挑战1– 研发成本高 主要体现在如下几个方面: 代码重复率高 在实际项目分工时,开发都是各自负责几个功能,即便开发之间存在功能重叠,往往也会选择自己实现,而不是类库共享,

从单体架构到微服务的服务化演进之路

本次分享的大纲如下: 传统应用开发面临的挑战 服务化实践 服务化不是银弹 服务化架构的演进方向 一 .传统应用开发面临的挑战 挑战1– 研发成本高 主要体现在如下几个方面: 代码重复率高 在实际项目分工时,开发都是各自负责几个功能,即便开发之间存在功能重叠,往往也会选择自己实现,而不是类库共享,主要原因如下: 从技术架构角度看,传统垂直架构的特点是本地API接口调用,不存在业务的拆分和互相调用,使用到什么功能就本地开发,非常方便,不需要过度依赖于其它功能模块: 从考核角度来看,共享很难推行.开发