《微服务设计》读书笔记

末鹿安然 提交于 2020-03-15 10:36:25
待做的:
学习框架: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.治理通过评估干系人的需求、当前情况 及下一步的可能性来确保企业目标的达成,通过排优先级和做决策来设定方向。对于已经达成一致的方向和目标进行监督。

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!