微服务笔记(1)--初识

微服务概念的提出和实践已经有多年,网上也有很多微服务的文章和教程。经过这段时间的学习,将自己对于微服务的理解和实践过程整理出来。


1.微服务从哪里来?

1.1微服务是一种软件架构风格

微服务并不是凭空产生的,它是随着软件架构不断发展进化而出现的产物。软件架构的发展大体上分为三个阶段:单体应用架构、分布式组件化应用架构、面向服务SOA应用架构。网上也有文章将微服务定义为SOA架构之后的第四代架构,并将流计算服务定义为第五代架构,怎么划分几代几代无所谓,只要能把是什么表达清楚即可。而根据“Microservice”这个概念的提出者-Martin Fewler本人的说法,微服务这个概念只是SOA架构的子集。其实微服务具体如何定义、又该划分到哪一代软件应用架构中都是次要的,理解微服务究竟意味着什么也许才更重要。

微服务是一种软件应用架构风格,并不特指某一项技术或某一个开发框架。我更倾向于把微服务理解为一种解决问题的思路和方法,它能提供一种不同的思维方式对软件项目开发运维的模式和流程进行解析。

1.2微服务不是万能的

微服务不是万能的,并不见得适用于所有项目。虽然微服务是在从单体应用到组件式应用再到面向对象服务这个过程中发展出来的,但并不意味着微服务就是最好的,也不意味着单体应用或组件式应用就是过时的、要被抛弃的。一切脱离实际项目需要而进行的软件应用架构设计都是空谈。软件应用架构的设计都要基于项目的实际需求进行考量,软件项目的规模、业务场景、目标用户等很多要素都应该是选取合适软件架构的依据。
从一个企业的角度来看,软件架构的发展其实是企业规模不断变大、业务量不断增加这一过程所带来的必然结果和要求。当企业刚刚起步时业务量很小,一个简单的单体应用就绰绰有余;当企业逐步扩大生产、提升规模时,业务量也渐渐增加,分布式组件化的应用再扩充一些基础硬件设施也能满足要求;然而当企业规模或业务量到达一定规模和复杂度时,原有的应用架构已经不堪重负了,这时候微服务也许是一个不错的选择。但现实是并不是所有企业都是这样的发展轨迹,也并不是所有客户都会达到相当规模及复杂度的业务量,单体应用能解决的强行使用微服务带来的恐怕是灾难。

没有最好的架构,只有最合适的架构!

2.微服务有哪些特点?

微服务既然作为一种软件架构风格,一定有其不同之处也就是与众不同的特点。就好比我们买衣服的时候会有商务风格、休闲风格等,只有当商品具备某些特点或元素时,我们才会称其具有“XX风格”。作为微服务这种软件架构风格的特点,就要同时看到其优点和缺点。

2.1优点

  • 易于开发和维护
  • 启动迅速
  • 局部修改容易部署
  • 技术栈不受限制
  • 按需伸缩

2.2缺点

  • 运维要求较高
  • 分布式的复杂性
  • 接口调整成本较高
  • 重复劳动

当然上面的优点和缺点都是相对的,在不同的场景下一些原本的优点可能变成缺点,缺点也可能变成优点。

3.微服务用到了哪些技术?

为了实现具备微服务这一风格的软件架构据需要一系列的技术,而为了确保这一过程的便捷化、标准化也需要一系列的工具。

3.1实现技术

  • 通信技术
  • 分布式架构
  • 容器技术
  • 安全协议

3.2自动化工具

  • 研发自动化工具
  • CI/DI工具
  • 运维自动化工具

4.微服务由哪些部分组成?

具备微服务这一风格的软件架构往往是由不同部分有机组合到一起的,而这些不同部分按照职责的区分可以大致划分到基础架构和后端架构。

4.1基础架构

  • 服务发现和注册组件
  • API网关组件
  • 服务容错组件
  • 监控告警日志组件
  • 认证授权组件
  • 统一配置管理组件

4.2后端架构

  • 消息队列中间件
  • 关系存储及其相关管理工具
  • 分布式NoSQL数据库
  • NewSQL数据存储区
  • 文件数据存储区
  • 数据流平台

5.微服务有哪些解决方案?

经过近些年的蓬勃发展,行业内已经涌现了多种具备微服务风格的软件架构。这些具体的微服务解决方案从侧重方向上大致可以分为偏向于开发型的、偏向于运维型的、偏向于无服务型的。而在开发语言上也是很丰富,JAVA、.NET、JavaScript、PHP、Go、Python等都能很好的支持。
微服务笔记(1)--初识_第1张图片

6.微服务怎样才能用好?

为了更好理解和使用微服务,最重要的是思维模式的转变。微服务并不单指一项具体的技术,也并不特指一种开发框架,更没有一系列的条条框框限制,我更愿意将它作为一种解决问题的思路,一个面对规模级别项目的切入点。根据软件项目实际需求,当你决定使用微服务时,同时也意味着你的思维模式要进行调整,也许你之前在单体应用项目中游刃有余的解决方式在微服务项目中就行不通了或者并不那么有效了。在思维模式的转变这一方面,再具体点就涉及到业务分析的方法论、开发团队的组织形式、开发运维的实施流程等。

6.1业务分析设计方法论

  • 领域驱动设计方法的运用

6.2组织、人员和文化

  • 组织团队的调整适应
  • 团队文化和行为的转变和提升
  • 培养必要的新技能和新能力
  • 小而活的团队组织管理

6.3开发和运维流程

  • 更频繁更快速的响应业务需求
  • 开发和运维过程管理的敏捷性
  • 优化质量保证流程
  • 加强安全和治理管理
  • 整合工具并构建DevOps平台

转变思维模式,尝试一种全新的思路去拆解复杂的问题,学会一种新的软件架构设计思路,这才是初识微服务所学到的最重要的内容!

你可能感兴趣的:(基础知识)