F1V3.0-2 平台2.X优点继承及问题解决

最新推荐文章于 2024-03-26 00:11:30 发布

原创最新推荐文章于 2024-03-26 00:11:30 发布 · 504 阅读

1 ·

CC 4.0 BY-SA版权

文章标签：

#模块化 #微服务

F1 同时被 2 个专栏收录

30 篇文章

订阅专栏

微服务

16 篇文章

订阅专栏

本文探讨了微服务架构如何克服传统OSGI框架的问题并发扬其优点，包括更彻底的模块化、依赖管理及动态加载等特性。通过独立开发、测试各微服务，解决了调试难题，并介绍了使用Feign客户端实现微服务间调用的方法。

上篇博文中讲到了平台2.X的优缺点，这篇博文讲一讲微服务架构是怎么发扬这些优点以及避免这些问题的。

1 优点继承和发扬

OSGI是模块化框架，符合模块化的三个标准，具有模块化、依赖管理、动态加载等优点。但归根结底，OSGI还是单体应用，有单体应用的一些固有问题，如资源冲突、可靠性等。
使用微服务架构后，每个服务都是一个独立的应用，是更为彻底的模块化。依赖管理、动态加载自然而然得到发扬。每个微服务都是独立应用，各独立应用间的依赖自然隔离，不存在冲突问题。每个微服务的部署、更新都是独立的，自然也不会影响其他微服务。

2 问题解决之道

2.1 调试问题、单元测试问题、Jar包引入问题

这几个问题都是OSGI框架带来的复杂性，使用微服务架构后，每个微服务都是独立的程序，独立进行开发、测试。开发过程又回到了以前熟悉的方式，调试、测试、Jar引入就是传统J2EE的开发模式，我们熟悉的感觉又回来了。
微服务开发和传统J2EE开发，主要区别在：
1）微服务一般把应用服务器内嵌到系统中，而传统J2EE则把程序部署到应用服务器上。这是一般情况，其实和是不是微服务本身没什么关系，微服务也可以外部署，传统J2EE也可以内嵌。内嵌的方式配置、开发、调试相对简单，只有运行main函数就行。而外部署的方式需要另外启动容器，相对麻烦点。
2）微服务间调用
微服务架构把一个个业务功能分成了多个微服务，微服务间难免存在互相调用，而传统J2EE开发都是进程间调用。为了解决这个问题，F1平台使用Feign代理的方式，让微服务调用和本地调用一致。
当一个服务确定需要被暴露出去时，就需要编写feignclient，如，服务B中有一个服务“add”，在其他服务中将使用到，f1-interface-B中，BClient编写如下：

@FeignClient("serviceB-ID")
public interface BClient {
    @RequestMapping(method = RequestMethod.GET, value="/add")
    String add(
            @RequestParam(value = "a") Integer a, 
            @RequestParam(value = "b") Integer b);
}

当服务A需要调用该服务时，首先引入f1-interface-B，并在主类上标识@EnableFeignClients(“扫描到BClient 的包路径”)，使用如下：

@Autowired
BClient bClient;

public int add() {
// 需要B的add服务
int res = bClient.add(10, 50);
return res;
}

可以看到，和本地调用基本没有区别。

2.2 Web页面开发问题

详见页面开发解决之道

2.3 开发启动慢问题

微服务架构后，开发模式如下：

微服务中心和UI中心部署在服务器上，只有开发中的微服务部署在本机。平台测试、调试只需要启动本机的微服务，这样能较大的提高启动速度。