最近阅读了周立的《春云与码头工人》收获挺大的,抽了一点时间对书中的内容做了总结。方便大家快速了解什么是春天的云,春云主要的功能及春云服务治理。如下博客的内容都出自这本书。
<强>什么是微服务
微服务架构风格是一种将一个单一应用程序开发为一组小型服务的方法,每个服务运行在自己的进程中,服务间通信采用轻量级通信机制(通常用HTTP资源API)。这些服务围绕业务能力构建并且可通过全自动部署机制独立部署。这些服务共用一个最小型的集中式的管理,服务可用不同的语言开发,使用不同的数据存储技术。
微服务架构应该具备以下特性:
-
<李>
每个微服务可独立运行在自己的进程里。
李 <李>一系列独立运行的微服务共同构建起整个系统。
李 <李>每个服务为独立的业务开发,一个微服务只关注某个特定的功能,例如订单管理,用户管理等。
李 <李>微服务之间通过一些轻量的通信机制进行通信,例如通过RESTful API进行调用。
李 <李>可以使用不同的语言与数据存储技术
李 <李>全自动部署机制李 <强>微服务架构的优点
易于开发和维护
-
<李>一个微服务只会关注一个特定的业务功能,所以它业务清晰,代码量较少。
单个微服务启动较快
-
<李>单个微服务代码量较少,所以启动会比较快。
局部修改容易部署
-
<李>单体应用只要有修改,就得重新部署整个应用,微服务解决了这样的问题。
技术栈不受限
-
<李>在微服务架构中,可以结合项目业务及团队的特点,合理地选择技术栈。
按需伸缩
-
<李>可根据需求,实现细粒度的扩展。
<强>微服务架构面临的挑战
运维要求高
-
<李>更多的服务意味着更多的运维投入。
分布式固有的复杂性
-
<李>使用微服务架构是分布式系统。对于一个分布式系统,系统容错,网络延迟,分布式事务等都会带来巨大的挑战。
接口调整成本高
-
<李>微服务之间通过接口进行通信。如果修改某一个微服务的API,可能所有使用了该接口的微服务都需要做调整。
重复劳动
-
<李>很多服务可能都会使用到相同的功能,而这个功能并没有达到分解为一个微服务的程度,这个时候,可能各个服务都会开发这一功能,从而导致代码重复。
<强>微服务整体架构图
<>强服务注册于发现
各个服务在启动时,将自己的网络地址等信息注册到服务发现组件中,服务发现组件会存储这些信息。
服务消费者可以从服务发现组件查询服务提供者的网络地址,并使用该地址调用服务提供者的接口。
各个微服务与服务发现组件使用一定机制(例如心跳)通信。服务发现组件如长时间无法与某为服务实例通信,就会注销该实例。
微服务网络地址发生变更(例如实例增减或者IP端口发生变化等)时,会重新注册到服务发现组件。使用这种方式,服务消费者就无须人工修改提供者的网络地址了。
<强> Fegion实现声明式休息调用
REST (Representational State Transfer),用中文翻译为“具象状态传输“(也有:“代表性状态传输“)。是由罗伊·托马斯·菲尔丁博士在2000年就读加州大学欧文分校期间在学术论文中提出的一个术语r定义了一组体系架构原则,您可以根据这些,包括使用不同语言编写的客户端如何通过HTTP处理和传输资源状态.Feign是一个声明式的WebService客户端。使用假装能让编写WebService客户端更加简单,它的使用方法是定义一个接口,然后在接口上添加注解,同时也支持jax - rs标准的注解.Feign也支持可插拔式的编码器和×××.SpringCloud对装进行了封装,使其支持SpringMVC标准注解和HttpMessageConverters.Feign可以与尤里卡和丝带组合使用以支持负载均衡。
