Kubernetes(K8S)學習筆記之一Kubernetes的基本概念以及架构 作者: lovingyu_er 时间: 2020-06-23 00:35:00 分类: 编程语言, 技术品鉴,Ubuntu,Kubernetes-K8S,运维优化,Microservice-微服务 评论 ####Kubernetes 集群 Kubernetes 協調一個高可用計算機集群，每個計算機作為獨立單元互相連結工作。 特點: 1. 將容器化的應用部署到集群，不需要綁定到某個特定的獨立的計算器。 2. 应用需要以将应用与单个主机分离的方式打包：它们需要被容器化。 3. Kubernetes 以更高效的方式跨群集自动分发和调度应用容器。 Kubernetes 是一个开源平台，并且可应用于生产环境。 ####K8S 集群包含的類型: Master ，Nodes ，前者負責調度整個集群。Nodes 負責運行應用。 其結構圖如下:  **Master負責管理整個集群**。Master協調集群中的所有活動，這些活動包括調度應用，維護應用的所需狀態，應用擴容以及推出新的更新。 **Node 是一個虛擬機或者物理機，它在Kubernetes集群中充當工作機器的角色**，可以理解為實際幹活的人。 其整体的架构图如下:  使用Minikube工具创建一个Cluster，你可以在官方的终端命令行有模拟的工具。 参考文档： 1. K8s miniKube工具部署简单的集群：```https://kubernetes.io/zh/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive/``` 2. K8s 开源仓库地址(golang真香):```https://github.com/kubernetes/kubernetes``` 3. K8s 官方文档:```https://kubernetes.io/zh/docs/home/```
微服务的基本介绍 作者: lovingyu_er 时间: 2020-03-20 18:14:00 分类: Microservice-微服务 评论 “微服务”一词来源于 Martin Fowler 的《Microservices》一文。微服务是一种架构风格，即将单体应用划分为小型的服务单元，微服务之间使用 HTTP 的 API 进行资源访问与操作。 微服务架构的演变更像是一个公司的发展过程，从最开始的小公司，到后来的大集团。大集团可拆分出多个子公司，每个子公司的都有自己独立的业务、员工，各自发展，互不影响，合起来则是威力无穷。 臃肿的系统、重复的代码、超长的启动时间带给开发人员的只有无限的埋怨，丝毫没有那种很舒服的、很流畅的写代码的感觉。他们把大部分时间都花在解决问题和项目启动上面了。 **通俗来说，微服务架构就是把一个大系统按业务功能分解成多个职责单一的小系统，并利用简单的方法使多个小系统相互协作，组合成一个大系统。** ** 微服务 约等于 模块式开发+分布式计算** 如果学科派一点，微服务架构就是把因相同原因而变化的功能聚合到一起，而把因不同原因而变化的功能分离开，并利用轻量化机制（通常为 HTTP RESTful API）实现通信。 ####微服务架构的优势 使用微服务架构能够为我们带来如下好处： #####1）服务的独立部署 每个服务都是一个独立的项目，可以独立部署，不依赖于其他服务，耦合性低。 #####2）服务的快速启动 拆分之后服务启动的速度必然要比拆分之前快很多，因为依赖的库少了，代码量也少了。 #####3）更加适合敏捷开发 敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行。服务拆分可以快速发布新版本，修改哪个服务只需要发布对应的服务即可，不用整体重新发布。 #####4）职责专一，由专门的团队负责专门的服务 业务发展迅速时，研发人员也会越来越多，每个团队可以负责对应的业务线，服务的拆分有利于团队之间的分工。 #####5）服务可以动态按需扩容 当某个服务的访问量较大时，我们只需要将这个服务扩容即可。 #####6）代码的复用 每个服务都提供 REST API，所有的基础服务都必须抽出来，很多的底层实现都可以以接口方式提供。 ####微服务架构的劣势 微服务其实是一把双刃剑，既然有利必然也会有弊。下面我们来谈谈微服务有哪些弊端，以及能采取什么办法避免。 #####1）分布式部署，调用的复杂性高 单体应用的时候，所有模块之前的调用都是在本地进行的，在微服务中，每个模块都是独立部署的，通过 HTTP 来进行通信，这当中会产生很多问题，比如网络问题、容错问题、调用关系等。 #####2）独立的数据库，分布式事务的挑战 每个微服务都有自己的数据库，这就是所谓的去中心化的数据管理。这种模式的优点在于不同的服务，可以选择适合自身业务的数据，比如订单服务可以用 MySQL、评论服务可以用 Mongodb、商品搜索服务可以用 Elasticsearch。 缺点就是事务的问题了，目前最理想的解决方案就是柔性事务中的最终一致性，后面的章节会给大家做具体介绍。 #####3）测试的难度提升 服务和服务之间通过接口来交互，当接口有改变的时候，对所有的调用方都是有影响的，这时自动化测试就显得非常重要了，如果要靠人工一个个接口去测试，那工作量就太大了。这里要强调一点，就是 API 文档的管理尤为重要。 #####4）运维难度的提升 在采用传统的单体应用时，我们可能只需要关注一个 Tomcat 的集群、一个 MySQL 的集群就可以了，但这在微服务架构下是行不通的。当业务增加时，服务也将越来越多，服务的部署、监控将变得非常复杂，这个时候对于运维的要求就高了 参考文档: 1.```http://www.uxys.com/html/SpringCloudTutorial/20200101/80674.html```