《微服务设计》读书笔记
《微服务设计》by Sam Newman,崔力强,张骏译
前言
什么是微服务?
微服务是一种分布式系统解决方案,推动细粒度服务的使用,这些服务协同工作,且每个服务都有自己的生命周具月。因为微服务主要围绕业务领域建模,所以免了由传统的分层架构引发的很多问题。微服务也整合了过去十年来的新概念和技术,因此得以避开许多面向服务的架构中的陷阱。
第1章 微服务
随着领域驱动设计、持续交付、按需虚拟化、基础设施动化、小型自治团队、大型集群系统这些实践的流行,微服务也应运而生。它并不是被发明出来的,而是从现实世界中总结出来的一种趋势或模式。但是没有前面提及的这些概念,微服务也很难出现。
很多组织发现细粒度的微服务架构可以帮助他们更快地交付软件,并且有更多机会尝试新技术。微服务在技术决策上给了我们极大的自由度,使我们能够更快地响应不可免的变化。
什么是微服务
微服务就是一些协同工作的小而自治的服务。
-
很小,专注于做好一件事(内聚性)
-
内聚性:把因相同原因而变化的东西聚合到一起,而把因不同原因而变化的东西分离开来。
-
自治性
一个微服务就是一个独立的实体,它可以独立的部署在PAAS(Platform As A Service 平台即服务)上,也可以作为操作系统进程存在。要尽量避免把多个服务部署到同一台机器上。
服务之间均通过网络调用进行通信,从而加强了服务之间的隔离性,避免紧耦合。
服务会暴露出API,然后服务之间通过这些API进行通信。
一个黄金法则:如果系统没有很好地解耦,那么一旦出现问题,所有的功能都将不可用。有一个黄全法则是你是否能够修改一个服务并对其进行部署而不影响其他任何服务?
主要好处
- 术异构性
- 弹性
- 扩展
- 简化部署
- 与组织结构相匹配
- 可组合性
- 对可替代性的优化
面向服务的架构 微服务架构可以认为是SOA的一种特定方法。
第2章 演化式架构师
如果一个服务决定通过HTTP暴露REST接口,另一个用的是protocol buffers,第三个用的是Java RMI,那么作为一个服务的消费者就需要支持各种形式的交互,这对于消费者来说简直就是噩梦。这也就是为什么我强调我们应该“担心服务之间的交互,而不需要过于关注各个服务内部发生的事情”。
第3章 如何建模服务
什么样的服务是好服务?
松耦合:如果做到了服务之间的松耦合,那么修改一个服务就不需要修改另一个服务。使用微服务最重要的一点是,能够独立修改及部署单个服务而不需要修改系统的其他部分,这真的非常重要。
一个松耦合的服务应该尽可能少地知道与之协作的那些服务的信息。这也意味着,应该限制两个服务之间不同调用形式的数量,因为除了潜在的性能问题之外,过度的通信可能会导致紧耦合。
高内聚:我们希望把相关的行为聚集在一起,把不相关的行为放在别处。因为如果你想改变某个行为的话,最好能够只在一个地方进行修改,然后尽快地进行发布。所以,找到问题域的边界就可以确保相关的行为能放在同一个地方,并且它们回合其它边界以尽量松耦合的形式进行通信。
第4章 集成
微服务之间通信的方式的选择: SOAP、XML_RPC、REST、Protocol Buffers
原则
- 避免破坏性修改:避免对某个服务做得一些修改会导致该服务的消费方也随之发生改变。
- 保证API的技术无关性
- 使你的服务易于消费方使用
- 隐藏内部实现细节
最快的集成形式:数据库集成。如果其他服务想要从一个服务获取信息,可以直接访问数据库。如果想要修改,也可以直接在数据库修改。
- 外部系统可以查看内部实现细节,并与其绑定在一起
- 消费方与特定的技术选择绑定在了一起
- 高内聚和低耦合做得都不好
同步还是异步?
如果使用同步通信,发起一个远程服务调用后,调用方会阻塞自己并等待整个操作的完成。如果使用异步通信,调用方不需要等待操作完成就可以返回,甚至可能不需要关心这个操作完成与否。
请求/响应:客户端发起一个请求,然后等待响应(同步)。注册回调(异步)
基于事件(异步):客户端不是发起请求而是发布一个事件,然后期待其他的协作者接收到该消息,并且知道该怎么做
针对请求响应方式,可以考虑两种技术:RPC和REST
远程过程调用(RPC):远程过程调用允许你进行一个本地调用,但事实上结果是由某个远程服务器产生的。
优点:易于使用。
缺点:
- 技术的耦合,有一些RPC机制与特定的平台紧密绑定
- 本地调用与远程调用并不相同。网络并不可靠。即使客户端和服务端都正常运行,整个调用也可能会出错。
- 脆弱性
REST:REST是受web启发而产生的一种架构风格。REST风格包含了很多原则和限制。其中重要的一点是资源的概念。REST本身并没有提到底层应该使用什么协议,尽管事实上最常用HTTP。REST架构风格声明了一组对所有资源的标准方法,而HTTP恰好也定义了一组方法可供使用。
基于事件的异步通信
微服务发布事件机制和消费者接受事件机制
- 如RabbitMQ的消息代理
- 使用HTTP来传播事件:ATOM
事件驱动架构和异步编程会带来一定的复杂性
第11章 规模化微服务
故障无处不在:规模化以后即使是最好的工具最昂贵的硬件,也无法避免它们发生故障的事实。
第12章 总结
微服务的原则