《微服务设计》读书笔记

待作的:
学习框架: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.治理经过评估干系人的需求、当前状况 及下一步的可能性来确保企业目标的达成,经过排优先级和作决策来设定方向。对于已经达成一致的方向和目标进行监督。
相关文章
相关标签/搜索