《微服务设计》读书笔记
待做的:
学习框架:nameko、double、spring cloud、书
微服务的定义:
一些协同工作的小而自治的服务
微服务的核心思想:
1.自治:
1)每个微服务(APP)可以独立部署到PAAS(platform as a service)上
2)作为服务方,需要避免方暴露过多给消费而产生耦合,从而降低服务的自治性。要封装好,服务方内部实现修改,不该影响到消费方。
2.细粒度:
1)解耦:避免系统臃肿、难以维护
2)内聚性:相同的东西放在一起
3.隔离性:
1)各服务直接均通过网络调用进行通信(而不是代码调用),避免了紧耦合
2)各服务之间通过API调用,API解耦性必须要好,以保证技术的选择不被限制
3)一个黄金法则:你是否能够修改一个服务并对其进行部署,而不影响其他任何服务?(独立部署)
微服务的优点:
1.细粒度-》扩展性好-》可以快速响应变化、快速交付-》可以尝试更多的新技术
2.增加了团队的自治力
3.技术异构性。可以根据不同的业务场景,选择不同的技术,来构架服务。比如某个APP对性能有特别高的要求。或者某些APP对底层数据库有特别的要求(图数据库、文档数据库、关系型数据库)。这点需要APP足够小,可以快速重写,从而降低风险。还有就是框架要支持多语言开发业务模块。
4.弹性(稳定性、可用性):第11章,详解
5.扩展:可以很容易把独立的服务,分割出去独立部署。通过构架来节省成本
6.简化部署:各服务可以独立部署,单个服务出错,也不会影响整体运行。风险可控,成本不高。
7.与组织结构匹配,可以组建小团队自治。第10章,详解
8.可组合性,第5章,详解
9.对可代替性的优化。可以有信心,也比较容易重写系统。(方便重构)
微服务的相关技术:
1.领域驱动设计
2.持续交付
3.按需虚拟化
利用云技术,按需创建机器并调整大小,方便扩展
4.基础设施自动化
5.小型自治团队
6.大型集群系统
分布式系统
7.共享库,要慎用,可能会成为耦合点(第4章再介绍)
关于团队:
1.拆成小团队,对自己的服务的全生命周期负责
2.团队自治
3.研究新技术,来实现自己的服务
构建微服务:
设施自动化
测试:
自动化测试,服务接口跑测试脚本
持续交付:
自动部署(日常、线上),自动测试
关于业务层:
1.使用“领域驱动设计”,先把业务场景确定,然后进行领域设计抽取模型,然后按照模型设计系统
2.业务边界来确定业务层各个APP的服务边界。所以对业务边界的划分很重要。可以根据领域驱动设计来划分
3.关于APP划分的几个思路:
1).时间维度:短时间内可以完全重写
2).复杂度维度:觉得够小(可控),就可以
3).团队维度:保证在一个小团队可以维护的范围内(康威定律,团队的组成,决定系统的架构)
4.APP越小,微服务带来的优缺点就越明显
5.微服务,小APP的缺点:管理复杂
服务管理:
1.接口管理:接口记wiwi、利用工具(?)
注意:
1.微服务的技术,比微服务的理念要变化快很多。所以要更多的关注设计思想,而不是某项技术
2.共享库(lib,前端框架)在微服务框架里,容易成为一个耦合点。不一定是个好注意
待研究:
接口注册,接口发现,统一管理
待学习:
1.持续交付理论
2.Alistair Cockburn 的 六边形 架构 理论( http:// alistair. cockburn. us/ Hexagonal+ architecture) 把 我们 从 分层 架构 中 拯救 出来, 从而 能够 更好 地 体现 业务 逻辑。
3.寻找一款好的建模工具,用熟他
4.构架原则(根据自己环境制定)https://www.12factor.net/
思考&问题:
1.每个服务端口的配置,接口URL是否能够统一管理?利用自动化部署工具,解决配置管理问题(日常和线上环境配置独立维护)
2.解决服务接口管理的问题,就可以大大降低服务管理的复杂性?寻找一个接口自动生成的工具,这解决了两个研发中常见的问题:(运行时框架的接口采用了 GraphQL ,并且告别了手动写接口的形式,全部利用视图勾选生成)
杜绝了手工约定接口时可能出现的拼写等错误。
能自动统计到所有对某一接口进行消费的页面,一旦接口进行调整,可以自动通知到下游,甚至能自动生成适配代码,不影响下游。
关于数据库:
1.数据库最好使用同一个技术栈的。除非有特殊的需求。方便管理和部署
关于技术异构与标准化:
1.APP内部可以实行技术异构,但是外部框架最好使用统一标准化的技术实现
关于构架师:
1.保证团队有共同的技术愿景,帮助程序员向客户交付他们想要要的系统
2.构架师不像建筑师,而像城市规划师。
3.构架师,不仅要考虑系统、用户。还要考虑开发者,运维人员的情况。
4.构架师,应该更多的关注服务的边界和区域之间的事。至于服务内部,应该给业务留出足够多的自治空间。(当然,最好也能提供一条框架模版)
5.构架师必须要要有时间和开发者一起工作,关注他们的开发效果和体验
6.构架师很多时候是在做取舍。而这些系统架构上的取舍,要根据以下几个原则来制定:符合公司战略目标、根据制定的原则(规范)、根据约定的实践(用任种技术)。通过示例代码和工具来实现
技术债务:
系统避免不了会产生一些技术债务,可能是临时项目,可能是系统目标发生改版。构架师应该要能察觉到它,并引到开发人员去消除技术债务。
代码治理:
1.范例。来自于真实案例,减少出错的可能。你写的漂亮代码
2.服务代码模版(代码库如springboot、tornado)。不应该是构架团队出,应该是业务团队商量出,或者收集意见专人维护(如webx)。内部开源也是个很好的办法。注意,它不应该是强制开发者使用的,否则会影响团队士气。代码模板可能会带来问题导致耦合(第4章讨论)
格言:
1.“你总提及的那个词, 它的含义与你想表达的意思并不一样。”
2.“规则对于智者来说是指导,对于愚蠢者来说是遵从。”
3.治理通过评估干系人的需求、当前情况 及下一步的可能性来确保企业目标的达成,通过排优先级和做决策来设定方向。对于已经达成一致的方向和目标进行监督。