微服务架构
微服务架构
yangty2017 发表于4个月前
微服务架构
  • 发表于 4个月前
  • 阅读 553
  • 收藏 25
  • 点赞 1
  • 评论 3

腾讯云 技术升级10大核心产品年终让利>>>   

微服务架构

    微服务是系统架构上的设计风格,主旨是将一个原本独立的系统拆分成多个小型服务,这些小型服务都在各自独立的进程中运行,服务之间通过基于http的RESTful AP进行通信协作。被拆分成的每一个小型服务都围绕着系统中的某一项或一些耦合度较高的业务功能进行构建,并且每个服务都维护着自身的数据存储、业务开发、自动化测试案例以及独立部署机制。

与单体系统的区别

    传统的企业系统中,针对一个复杂的业务需求通常使用对象或业务类型来构建一个单体项目。

    在项目中通常将需求分为三个主要部分:数据库、服务端处理、前端展现。在业务发展初期,由于所有的业务逻辑在一个应用中,开发、测试、部署、都比较容易方便。但是企业发展,系统为了应对不同的业务需求会不断为该单体项目增加不同的业务模块;同时随着移动端设备的进步,前端展现模块已经不仅局限于web的形式,这对于系统后端向前端的支持需要更多的接口模块。单体应用由于面对的业务需求更为宽泛,不断扩大的需求会使得单体应用变得越来越臃肿。单体应用的问题就逐渐凸显出来,由于单体系统部署在一个进程中,如果修改了一个小的功能,为了部署上线会影响其他的功能运行。并且单体应用中的这些功能模块的使用场景、并发量、消耗的资源类型都各有不同,对于资源的利用又相互影响,这样使得我们对各个业务模块的系统容量很难给出较为准确的评估。所以,单体系统在初期虽然非常方便的进行开发和使用,但是随着系统的发展,维护成本会变得越来越大,且难以控制。

微服务架构优点

  • 易于开发和维护:一个微服务只关注一个特定的业务功能,所以它业务清晰、代码量少。开发和维护单个微服务相对简单;
  • 局部修改容易部署:对于某个微服务进行修改,只需要重启这个服务即可;
  • 单个微服务启动较快:单个微服务代码量少,启动快;
  • 技术栈不受限制:可以结合项目业务及团队特点,合理选择技术栈,比如某些服务使用mysql,某些使用Neo4j
  • 按需伸缩:根据需求,实现细粒度的扩展。例如某个微服务遇到了瓶颈,可以结合这个微服务的业务特点,增加内存,升级cpu或者横向扩展节点。

微服务架构的缺点

  • 运维成本要求较高:更多的服务需要投入运维,需要保证几十个甚至几百个服务正常运行与协作;
  • 分布式固有复杂性:使用微服务构建的是分布式系统,系统容错,网络延迟,分布式事务
  • 接口调整成本高:微服务之间通过接口进行通信。如果修改一个微服务API,可能所有使用了该接口的微服务都需要做调整;
  • 重复劳动:很多服务功能都会使用相同的功能,而这个功能并没有达到分解为一个微服务的程度,这时可能各个服务都会开发这一功能,从而导致代码重复。

 

如何实施微服务

运维的新挑战:

      微服务架构中,运维人员需要维护的进程数量会大大增加,运维过程中需要更多的自动化,需要运维人员具备一定的开发能力来编排运维过程并能自动运行起来。

接口的一致性:

      虽然拆分了服务,但是业务逻辑上还是存在依赖,微服务之间的依赖关系是从代码依赖变为了服务间的通信依赖。需要更加完善的接口和版本管理。

分布式的复杂性:

      网络延迟、分布式事务、异步消息等

服务组件化:

      微服务架构中,需要对服务进行组件化分解。每一个服务都独立开发、部署,可以有效避免一个服务的修改引起整个系统的重新部署。

按业务组织团队:

       由于每一个微服务都是针对特定业务的宽栈或者全栈实现,需要负责数据持久化,负责用户接口定义等跨领域专业的职能。因此微服务团队建议按照业务线的方式拆分,减少服务内部修改产生的内耗;另一方面团队边界变得清晰;

持续性迭代:

      微服务架构实施不是以完成开发与交付并将成果交接给维护者为最终目标。开发团队通过了解服务在具体的生产环境中的情况,可以增加对具体业务的理解,甚至会逐步超过产品经理,很容易通过生产环境发现这些特殊潜在的问题与需求。

      所以微服务架构是适用于持续关注服务的运作情况,并不断分析以帮助用户来改善业务功能。

智能断电与哑管道:

    单体应用中,组件之间通过函数调用的方式进行交互协作。微服务架构中,组件间通信模式改成RPC方式调用,会导致微服务之间产生烦琐的通信,所以需要粗粒度通信协议。

    微服务架构通常使用两种服务调用方式:

     第一种,使用HTTP的RESTful API或者轻量级的消息发送协议,实现信息传递与服务调用的触发。

     第二种,通过轻量级消息总线传递消息(Spring Cloud Bus),类似RabbitMQ等异步交换的消息中间件。

去中心化治理:

      当采用集中化治理方案时,通常在技术平台上统一标准。再实施微服务架构时,通过采用轻量级的         契约定义接口,对于服务本身的技术平台不再那么敏感,整个微服务架构系统中的各个组件针对其不同     的业务特点选择不同的技术平台,不会出现杀鸡用牛刀的尴尬处境。

      不是每一个问题都是钉子,不是每一个解决方案都是锤子。

去中心化管理数据:

    实施微服务架构时,希望每一个服务管理其有的数据库,在区中心化过程中,除了将原数据库中的存储内容拆分到新的同平台的其他数据库实例中之外,也将特殊结构的或者业务特性的数据存储到一些其他技术的数据库实例中,比如日志信息存储到MongoDB中,用户登录信息存储到Redis中。

基础设施自动化:

       自动化测试、自动化部署

容错设计:

       微服务架构中,快速检测出故障源并尽可能地自动恢复服务是必须被设计和考虑的。

每个服务中实现监控和日志记录的组件,比如服务状态,断路器状态,吞吐量,网络延迟等关键数据的仪表盘;

演进式设计:

       要实施一个完美的微服务架构,需要的考虑的设计与成本都非常大,对于没有足够经验的团队,甚至比单体应用付出更多的代价。所以不管是产品还是项目初期,以单体传统的方式来设计和实施,一方面系统体量并不会很大,构建和维护成本都不高。另一方面,初期的核心业务在后阶段通常也不会有较大的变化。随着系统的发展或者业务需要,可以将一些经常变动或是一定时间效应的内容进行微服务处理,并逐渐将原来在单体系统中多变的模块逐步拆分出来,而稳定不太变化的模块就形成了一个微服务存在于整个架构中。

 

常见的微服务架构图

微服务设计模式:https://my.oschina.net/yangty2017/blog/993744

 

共有 人打赏支持
粉丝 3
博文 34
码字总数 25828
评论 (3)
leixu2
微服务中, 数据库设计 是怎样?
比如 xx 列表需要以来用户信息,数据库独立的,是经过http接口检索出用户信息再合并吗?
yangty2017

引用来自“leixu2”的评论

微服务中, 数据库设计 是怎样?
比如 xx 列表需要以来用户信息,数据库独立的,是经过http接口检索出用户信息再合并吗?
业务,数据都是独立的,至于通过rest还是消息通道就看驱动事件模型的业务场景
leixu2

引用来自“leixu2”的评论

微服务中, 数据库设计 是怎样?
比如 xx 列表需要以来用户信息,数据库独立的,是经过http接口检索出用户信息再合并吗?

引用来自“yangty2017”的评论

业务,数据都是独立的,至于通过rest还是消息通道就看驱动事件模型的业务场景
能否详细说明一下。。

比如 有 2个库 用户信息在A库,业务数据在B库(并没有冗余用户基本信息,只是关联ID)。

当我一个功能需要从B库获取数据并且还要展示创建者,你们是怎么实现讷?
×
yangty2017
如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
* 金额(元)
¥1 ¥5 ¥10 ¥20 其他金额
打赏人
留言
* 支付类型
微信扫码支付
打赏金额:
已支付成功
打赏金额: