實現微服務的實現方式有很多，上次我們討論了微服務治理實現的內外之別，下面我們再來說說支撐微服務平臺的哪些技術的方式和抉擇。
爲什麼要全面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化，項目型驅動的公司如何去應對不同基礎設施所帶來的微服務化的挑戰呢？何時需要進行微服務化設計？如何進行微服務化的設計呢？跨語言應用的微服務如何去做？在後邊的內容中我將展開講解。