文章目录
- part1_系统架构演变
- 原始集中式架构
- 垂直拆分
- 分布式服务
- 面向服务架构SOA
- 微服务
- Part_2服务调用方式
- RPC和HTTP
- Part3_Spring_RestTemplate
part1_系统架构演变
随着互联网的发展网站应用的规模不断扩大。需求的激增带来的是技术上的压力。系统架构也因此不断的演进、升级、迭代。从单一应用到垂直拆分到分布式服务到SOA以及现在火热的微服务架构还有在Google带领下来势汹涌的Service Mesh。我们到底是该乘坐微服务的船只驶向远方还是偏安一隅得过且过
原始集中式架构
当网站流量很小时只需一个应用将所有功能都部署在一起以减少部署节点和成本。举个例子一个应用的各项功能全部部署在一个Tomcat中。
存在的问题
- 单点故障假设该服务器崩溃、整个应用将瘫痪
- 并发很低。
- 代码耦合度过高不同服务全在一个工程中互相调用、难以进行独立优化。你不知道你做的优化是否会影响调用这个功能的某个模块
- 针对并发高的服务无法进行水平扩展。
优点
- 维护之间出现问题只需要复盘部署该应用的服务器如Tomcat
用户到数据库之间只有一条通道。
垂直拆分
针对原始架构进行了解耦。当访问量逐渐增大单一应用无法满足需求此时为了应对更高的并发和业务需求我们根据业务功能对系统进行拆分每个业务功能单独作为一个应用。
优点
- 系统拆分实现了流量分担解决了并发问题
- 可以针对不同模块进行优化
- 方便水平扩展可针对特定模块进行负载均衡或集群部署容错率提高
缺点
- **系统间相互独立无相互调用、**会有很多重复开发工作影响开发效率存在大量代码冗余。
- 增加维护成本。
分布式服务
当垂直应用越来越多应用之间交互不可避免分布式架构将服务分为基础服务和业务功能也是一种服务、基础服务具有和数据库交互的权限、且可以被不同的业务功能业务进行调用。此时、服务之间的调用是关键
优点
- 解决了垂直拆分下代码冗余的问题将基础服务进行了抽取系统间相互调用提高了代码复用和开发效率
缺点
- 系统间耦合度又变高了调用关系错综复杂难以维护
面向服务架构SOA
SOA解决的传统分布式不同服务之间调用关系错综复杂的缺陷、同时也解决的垂直拆分的服务之间独立的代码冗余问题。
以Dubbo框架的架构为例
加入注册中心组件、每个服务都需要注册到注册中心进行集中管理、服务之间的调用、负载均衡、服务授权等都通过注册中心进行中转。
通过注册中心可以监视各个服务的动态与详情。
进一步说明传统分布式无注册中心出现的问题。
- 服务越来越多需要管理每个服务的地址
- 调用关系错综复杂难以理清依赖关系
- 服务过多服务状态难以管理无法根据服务情况动态管理
优点
- SOA服务注册中心实现服务自动注册和发现无需人为记录服务地址
- SOA服务自动订阅服务列表自动推送服务调用透明化无需关心依赖关系
- 动态监控服务状态监控报告人为控制服务状态
缺点:”服务划分粒度不够细“
微服务
微服务其实是SOA的更细粒度版。
微服务与SOA相比具有更明显的特性
- 单一职责微服务中每一个服务都对应唯一的业务能力做到单一职责
- 微微服务的服务拆分粒度很小例如一个用户管理就可以作为一个服务。每个服务虽小但“五脏俱全”。SOA没有这么“微”
- 面向服务面向服务是说每个服务都要对外暴露Rest风格服务接口API。并不关心服务的技术实现做到与平台和语言无关也不限定用什么技术实现只要提供Rest的接口即可。
- 自治自治是说服务间互相独立互不干扰
- 团队独立每个服务都是一个独立的开发团队人数不能过多。
- 技术独立因为是面向服务提供Rest接口使用什么技术没有别人干涉
- 前后端分离采用前后端分离开发提供统一Rest接口后端不用再为PC、移动段开发不同接口
- 数据库分离每个服务都使用自己的数据源
- 部署独立服务间虽然有调用但要做到服务重启不影响其它服务。有利于持续集成和持续交付。每个服务都是独立的组件可复用可替换降低耦合易维护
总结:
微服务架构是 SOA 架构思想的一种扩展更加强调服务个体的独立性、拆分粒度更小
Part_2服务调用方式
RPC和HTTP
无论是微服务还是SOA都面临着服务间的远程调用。那么服务间的远程调用方式有哪些呢
常见的远程调用方式有以下2种
-
RPCRemote Produce Call远程过程调用类似的还有RMI远程方法调用
基于原生传输层的TCP通信速度快效率高。但需要自定义数据格式早期的webservice(cxf)之前的dubbo都是RPC的典型代表。
-
Httphttp是一种网络传输协议也是基于TCP但在应用层规定了数据传输的格式。现在客户端浏览器与服务端通信基本都是采用Http协议也可以用来进行远程服务调用。缺点是消息封装臃肿即不管什么特点的数据都要用http格式封装优势是对服务的提供和调用方没有任何技术限定自由灵活更符合微服务理念
现在热门的Rest风格就可以通过http协议来实现。
Http客户端工具
- HttpClient
- OKHttp
- URLConnection
Part3_Spring_RestTemplate
Spring提供了一个RestTemplate模板工具类对基于Http的客户端进行了封装并且实现了对象与json的序列化和反序列化非常方便。RestTemplate并没有限定Http的客户端类型而是进行了抽象目前常用的3种都有支持
- HttpClient
- OkHttp
- JDK原生的URLConnection默认的
首先在项目中注册一个RestTemplate对象可以在启动类位置注册
SpringBootApplicationpublic class HttpDemoApplication {public static void main(String[] args) {SpringApplication.run(HttpDemoApplication.class, args);}Beanpublic RestTemplate restTemplate() {return new RestTemplate();}}
在测试类中直接Autowired注入
RunWith(SpringRunner.class)SpringBootTest(classes HttpDemoApplication.class)public class HttpDemoApplicationTests {//注入上段代码注册的restTemplateAutowiredprivate RestTemplate restTemplate;Testpublic void httpGet() {// 调用springboot案例中的rest接口User user this.restTemplate.getForObject("http://localhost/user/1", User.class);System.out.println(user);}}
通过RestTemplate的getForObject()方法传递url地址及实体类的字节码RestTemplate会自动发起请求接收响应并且帮我们对响应结果进行反序列化。 
学习完了Http客户端工具接下来就可以正式学习微服务了。