微服务设计
2021-02-27 20:37:06 1 举报AI智能生成
登录查看完整内容
微服务设计
作者其他创作
大纲/内容
微服务设计
第二章 演化式架构师
架构师的一个重要职责是，确保团队有共同的技术愿景，以帮助客户交付他们想要的系统
架构师的演化视角
与建造建筑物相比，在软件中我们会面临大量的需求变更，使用的工具和技术也具有多样性
不是一开始设计出完美产品，而是去设计一个合理的框架，在框架下慢慢演化出正确的产品，并且一旦学到更多的知识，可以更容易的应用到系统中
需要相应变化
变化难于预见
避免过于详尽的设计
职责之一就是保证系统适合开发人员在其上工作
分区
区域就是服务边界或者一些粗粒度的服务群组
更多的关注区域之间的事情
考虑服务之间的交互和对整个系统的健康状态进行监控
需要特别小心，因为在区域间发生的错误很难纠正
一个原则性的方法
系统设计都是在做取舍，在微服务构架中更是
战略目标
确保技术层面和战略目标一致
原则
为了和更大的目标保持一致而制订的具体规则
不是一成不变的
最好不要超过十个，或者写在海报等显著的位置，不然很难记住
原则越多，发生重叠和冲突的可能性越大
12Factors
https://www.12factor.net
Heroku
约束很难（或者说是不可能改变），原则是我们自己决定的
应该显示的指定哪些是原则，哪些是约束
实践
保证原则能够实施，指导完成任务
通常和技术相关，比较底层，开发人员容易理解
比较偏技术层面，所以改变频率高于原则
实践应该巩固原则
将原则和实践相结合
有些东西对一些人来说是原则，对另一些人来说可能是实践
要有一些重要的原则来指导系统的演化，同时有一些细节来指导如何实现这些原则
真实世界的例子
要求的标准
做取舍的重要因素
系统允许多少可变性
优化单个服务自治性的同时，要兼顾全局
清楚地定义出一个好服务应有的属性
监控
清晰的描绘出跨服务系统的健康状态
集中管理日志和监控
接口
选用少数几种明确的接口技术
有助于新消费者的集成
架构安全性
保证每个服务都可以应对下游服务的错误请求
一个运行异常的服务可能会毁了整个系统
没有很好的处理下游请求的服务越多，系统就越脆弱
独立地连接池
断路器
代码治理
范例
开发人员更喜欢看和运行代码
优秀的范例来自真实项目
裁剪服务代码模板
开发人员想要实现一个新服务时，所有实现核心属性的那些代码应该是现成的
基于JVM的开源微容器
Dropwizard
http://www.dropwizard.io
Karyon
https://github.com/Netflix/karyon
Hystrix
https://github.com/Netflix/Hystrix/
数据指标发送到中心Graphite服务器
https://github.com/dropwizard/metrics
针对自己的开发实践裁剪出一个服务代码模板
提高开发速度
保证服务质量
多个技术栈，多个技术模板
通过模板反向控制技术栈
创建服务代码模板不是某个中心化工具的职责，也不是指导（即使是通过代码）我们应怎样工作的架构团队的职责。应该通过合作的方式定义出这些实践，团队也要负责更新这个模板（内部开源的方式能够很好的完成这项工作）
应该可以选择是否使用服务代码模板，强制使用的，一定要确保能够简化开发工作
在重用代码的驱动下，可能会引入服务之间的耦合
技术债务
从更高的层次出发，理解如何做权衡
理解债务的层次及其对系统的影响非常重要
例外管理
使用拥有更好自治性的微服务团队，他们有更大的自由度来解决问题
组织不能对开发人员有非常多的限制
集中治理和领导
治理
治理通过评估干系人的需求、当前情况及下一步的可能性来确保企业目标的达成，通过排优先级和做决策来设定方向。对于已经达成一致的方向和目标进行监督
COBIT 5
治理是一个小组活动
架构师领导这个小组，每个团队有人参与
建设团队
伟大的软件来自伟大的人
职责
愿景
确保在系统级有一个经过充分沟通的技术愿景，这个愿景可以帮助你满足客户和组织的需求
同理心
理解你所做的决定对客户和同事带来的影响
合作
和尽量多的同事进行沟通，从而更好地对愿景进行定义、修改及执行
适应性
确保你的客户和组织需要的时候调整技术愿景
自治性
在标准化和团队自治之间寻找一个正确的平衡点
治理·
确保系统按照技术愿景的要求实现
第一章 微服务
领域驱动设计
Eric Evans
用代码呈现真实世界的重要性，更好的建模
六边形架构理论
http://alistair.cockburn.us/Hexagonal+architecture
脱离分层架构，更好的体现业务逻辑
借助虚拟化平台，能够按需创造机器并且调整大小，借助基础设施的自动化很容易从一台扩展到多台
持续交付
按需虚拟化
基础设置自动化
小型自治团队
大规模集群系统
概念
是一种分布式系统解决方案，推动细粒度服务的使用，这些服务协同工作，且每个服务都有自己的生命周期。是一些协同工作的小而自治的服务
很小，专注于做好一件事
内聚性
单一责任原则(Single Responsibility Principle)
http://programmer.97things.oreilly.com/wiki/index.php/The_Single_Responsibility_Principle
把相通原因而变化的东西聚合在一起，而把因不同原因而变化的东西分开
根据业务边界来确定服务的边界，服务专注于边界之内
容易确定某个功能的代码应该放在哪里
避免代码库过大衍生出来的各种问题
粒度
在两周之内完全重写
足够小既可以，不要过小
如果你不再感觉代码库过大，可能它就足够小了
与团队结构匹配
一个小团队能够正常维护
可以很好的管理复杂性的情况下，尽可能的小
服务越小，微服务架构的优点和缺点就更明显
更好的独立性
更复杂的大量服务管理
可以部署在PAAS(Platform AS A Service，平台即服务)的独立实体
避免多个服务部署到同一台机器上
简化分布式系统的构建
服务之间通过网络调用进行通信
加强了服务的隔离性
避免紧耦合
黄金法则：服务可以独立修改，一个服务的部署不会引起消费方的变动
暴露过多
消费方和服务的内部实现产生耦合
选择与技术不相关的API实现方式
保证技术选择不被限制
好处
技术异构性
在不同的服务中使用最适合的技术
可以更快的采用新技术，并且理解这些新技术的好处
可以选择风险最小的服务来采用新技术，即便出现问题也容易处理
可以快速采用新技术对很多组织来说是非常有价值的
但是为了同时使用多种技术，也需要付出一定的代价
有些组织会限制语言的选择
更小的服务（两周内可以被重写）可以降低多技术栈的风险
寻求平衡
弹性
舱壁
系统中的一个组件不可用了，但是并不会导致级联故障，系统的其他部分还可用
服务边界是一个明显的舱壁
微服务可以改进弹性，但是需要谨慎对待
使用了分布式系统，网络和机器都会是问题
扩展
可以按照需要扩展服务
把不需要扩展的服务运行在更小的性能稍差的服务上
简化部署
各个服务独立部署
更快的对特定部分的代码进行部署
出现问题只影响一个服务
容易快速回滚
更快的使用新功能
与组织结构相匹配
小型代码库上工作的小团队更加高效
更好的匹配架构和组织结构
避免出现过大的代码库
方便迁移服务所有权
避免异地团队的出现
可组合性
分布式系统和面向服务的架构的好处是易于重用已有功能
对可替代性的优化
可以在需要时轻易的重写或者删除不再需要的服务
面向服务的架构
SOA(service-oriented architecture，面向服务的架构)是一种设计方法，其中包含多个服务，而服务之间通过配合提供一系列功能
服务之间通过网络调用，而不是进程内调用的方式进行通信
一个服务通常以独立的形式存在于操作系统进程中
应对臃肿的单块应用程序，提高系统的可重用性
问题
通信协议的选择
第三方中间件的选择
服务粒度如何确定
指导原则的正确性
可以认为微服务架构是SOA的一种特定方法
共享库
缺点
无法选择异构的技术
失去独立地对系统某一部分进行扩展的能力
除非是动态链接库，否则在更新时需要重新部署整个进程
无法独立地部署变更
缺乏明显的接缝来建立架构的安全性保护措施
无法确保系统的弹性
使用共享代码来做服务之间的通信，会成为耦合点
模块
模块分解技术
允许对模块进行生命周期管理
把模块部署到运行的进程中
在不停止整个系统的前提下对某个模块进行修改
Java9可能源生支持
OSGI(Open Source Gateway Initiative，开放服务网关协议)
Erlang
内嵌在语言的运行时中
限制采用新技术和独立对服务进行扩展的能力
可能导致使用过度耦合的集成技术
缺乏接缝来进行安全性保护
模块会迅速的和其他代码耦合在一起，从而失去意义
没有银弹
需要面对系统的复杂性
第三章 如何建模服务
好的服务
松耦合（Loose Coupling）
能够独立修改及部署单个服务而不需要修改系统的其他部分
尽可能的少知道与之协作的那些服务的信息
限制不同形式调用的数量
高内聚（High Cohesion）
相关的行为放在一起，把不相关的放在别处
改变某个行为的话，最好能够只在一个地方进行修改，然后就可以尽快的发布
找到问题域的边界确保相关的行为能放在同一个地方，并且服务间尽量用松耦合的形式进行通信
限界上下文（bounded context）
任何一个给定的领域都包含多个限界上下文，每个限界上下文中的东西（模型）分成两部分，一部分不需要与外部通信，另一部分则需要
每个上下文都有明确的接口，决定了暴露哪些模型给其他上下文
一个显式边界限定的特定职责
http://blog.sapiensworks.com/post/2012/04/17/DDD-The-Bounded-Context-Explained.aspx
细胞之所以会存在，是因为细胞膜定义了什么在细胞内，什么在细胞外，并且确定了什么物质可以通过细胞膜
共享的隐藏模型
共享模型会在多个不同的进程中使用，并且在每个限界上下文中都会存在相应的实体，不过，这些实体仅仅是在每个上下文的内部表示而已
共享模型而不应该共享内部
模块和服务
按照限界上下文，使用模块对其进行建模，同时共享和隐藏模型
成为绝佳的微服务候选
微服务和限界上下文保持一致
先使用一段时间单模块系统，等系统稳定后，在确定把哪些东西作为服务划出去
过早划分
过早将一个系统划分成微服务的代价非常高，尤其是面对新领域时
很多时候，将一个已有的代码库划分成微服务，要比从头开始构建微服务简单的多
业务功能
在考虑组织内的限界上下文时，不应该从共享数据的角度来考虑，而应该从上下文能够提供的功能来考虑
先考虑上下文是做什么的，然后再考虑需要什么数据
逐步划分上下文
一开始识别出粗粒度的限界上下文
可能包含一些嵌套的限界上下文
嵌套上下文和顶层上下文层次
和组织架构匹配的更合适
嵌套上下文更容易做测试
粗粒度打桩
业务概念的沟通
修改系统的目的是为了满足业务要求
基于业务领域的软件建模不应该只限于限界上下文的概念
组织内部共享的那些术语和想法，也应该被反映到服务的接口上
以跟组织内通信相同的方式，来思考微服务之间的通信形式是非常有用的
通信形式在整个组织范围内都非常重要
技术边界
按照技术边界建模并不总是错误的，但是，不应该作为考虑的首要方式
0 条评论
回复 删除
下一页
