实现微服务的实现方式有很多,上次我们讨论了微服务治理实现的内外之别,下面我们再来说说支撑微服务平台的哪些技术的方式和抉择。
为什么要全面kubernetes化?
其实原因很简单,我们有两套微服务治理的基础设施。如果kubernetes具有微服务治理的基础设施,那我们为什么不利用起来而是去再建设一套呢。本来去建设维护一套基础设施的压力就很大。
全面kubernetes化带来的问题有哪些?
进行全面kubernetes化的前提是应用的容器化,应用的无状态化(有状态的应用对基础设施的要求高,不过也可以使用kubernetes来做治理)等。应用的改造成本增加。
当我们使用了kubernetes的基础设施作为微服务治理的基础设施时,应用对kubernetes平台就产生了强依赖性,并且kubernetes的本身的建设和运维就是一个不太容易的事情。
面向C端提供服务的公司建设这样一套自主的基础设施获益肯定是巨大的。但是以项目型驱动的公司将微服务全面kubrnetes化并不能获得多大的好处。
下面我以java项目为例来讲解如何将应用全面kubernetes化。
kubernetes 上原生的 Spring Cloud
为了原生支持kubernetes的基础设施,Spring 发布了 Spring Cloud Kubernetes 。Spring Cloud官方提供通用的借口来调用Kubernetes的服务,让Spring Boot程序能够更容易的在Kubernetes中运行。
主要特点如下:
- 使用etcd作为服务中心替代Eureka
- 使用configmap作为配置后端代替Spring cloud congfig
- 使用ingress作为网关替代zuul或Spring cloud gateway
应用升级
修改POM配置文件增加spring cloud strter kubernetes的依赖。
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-kubernetes</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-kubernetes-config</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-kubernetes-ribbon</artifactId>
</dependency>
或者全部引入:
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-kubernetes-all</artifactId>
</dependency>
代码的改造并不大。
启用服务发现
@SpringBootApplication
@EnableDiscoveryClient
public class Application {
public static void main(String[] args) {
SpringApplication.run(Application.class, args);
}
}
这个原来的代码没有变化。在application.properties
中增加配置,让应用可以发现所有kubernetes命名空间的服务。
spring.cloud.kubernetes.discovery.all-namespaces=true
启用配置
在application.properties
中增加配置,开启自动配置
spring.cloud.kubernetes.config.enabled = true
网关配置
网关的路由配置直接通过注入ingress就可以了。
其他语言
其他语言都有对etc和configmap的相应的库的支持,只需要引入就可以。比如python的python-etcd。go的etcclient。
kubernetes官方也提供了相应的客户端供其他语言来使用。
后记
上次我提到我们所做的技术选型不是全面的kubernetes化,项目型驱动的公司如何去应对不同基础设施所带来的微服务化的挑战呢?何时需要进行微服务化设计?如何进行微服务化的设计呢?跨语言应用的微服务如何去做?在后边的内容中我将展开讲解。