2019-07-02 14:30

　　大家下午好！我的演讲题目分两部分，一是AKS支撑微服务架构，另外一个是DevOps加速微服务迭代开发。

　　我叫马平，是微软全球技术黑带，微软全球技术黑带是一个部门名称，在这个部门中基本是一些技术专家，我负责的是容器、中间件、微服务、Serverless和DevOps等。

　　目前微软在云上的认证有两个专家级别的证书，这两个证书强烈向大家推荐考一下。

　　我们在谈论一个问题时首先要知道谈论这个问题的范围。（图）7月2号、7月3号所有的议题内容基本在这张图上都能找到。IT发展到今天分为三大板块：

　　1.IT的基础架构，就是网络、计算、存储；

　　2.数据架构，数据架构不要理解成为光是数据库，包括非数据库，大数据、人工智能，因为人工智能如果没有数据、没有大数据的话，是玩不转的；

　　3.与微服务相关的就是应用架构。应用架构层发展到今天有各种各样的，如两层、三层、SOA等等，今天叫微服务，微服务架构比较有特点，它虽然是应用层的架构，但对底层架构、对数据层架构都有要求，并不是只在应用层考虑就可以。所以大家讨论微服务架构时一定要明确，微服务架构虽然在应用层架构，实际上对底层基础架构、数据架构都有要求，甚至对于持续集成、持续发布、服务发现等等也都有要求。这是我们在谈论一个IT问题时需要明确这个问题属于哪个范围。

　　一、微服务架构基本概念

　　一般我讲东西的时候不愿意讲概念，特别是讲太底层的概念，习惯的是首先这个东西为什么会有，把这个东西想清楚了，这门技术就会有自己的独立判断，它有没有发展前景，是不是基于新的技术架构应该采用的微服务架构。

　　为什么要采用它？当出现什么样的问题时会考虑微服务？其实有一点大家可以很明确，如刚刚说的三层架构，底层基础架构，有一天忽然发现不管底层基础架构怎么变，都难以承受达到一定程度的高并发的用户请求数的响应。

　　早期我做中间件，做一个底层集群，多少节点支撑多少用户量级的并发数？我知道最高是16个节点。但这个并发数也是有限的，再增加怎么办？这就是问题。应用高并发存在性能瓶颈这一项，如果应用存在类似问题，基本上要考虑微服务。业务复杂性、团队规模日益扩大、单体应用维护升级部署难度加大，这些在我看来不是必然因素，因为这些因素可以通过管理去解决，可以通过设计去解决，但是高并发是一个硬的，不能支撑就是不能支撑，100台机器组成一个集群不现实，无法维护，这是为什么要使用微服务。

　　微服务架构：What？

　　微服务架构是随着云计算的发展应运而生的一种微软设计风格，与之对立的是传统的单体架构。

　　除了技术视角，给大家一个业务视角，单一职责原则，一个微服务做一件事情，不要一个微服务做很多事情。然后再说这个技术实现特点是什么？一个微服务就是一个独立的进程。是按照业务而不是技术的边界来确定一个微服务。从业务视角，每一个微服务是做一件事情，而且这一件事情是有一个明确的业务边界，所以能做到这一点，就知道微服务大概是什么样的架构。

　　从技术人员角度来讲，因为每一个微服务是一个独立的进程，可以想像将来的应用是分布式应用，不是一个应用。

　　微服务架构：Why？

　　比如迭代效率慢，提升迭代效率是可以做到的，因为每个服务做成微服务以后，微服务是独立开发部署，不需要依赖于其他的微服务。

　　弹性扩展，高可用，怎么做到？每一个微服务都可以做到自己的弹性扩展，想扩展到多少个就扩展到多少个，假设底层硬件是足够支撑情况下。

　　容错，不可能某一个微服务down掉就会导致整个应用全部崩溃，这种情况不允许出现，但这种情况在单体应用当中经常会出现。单体应用当中某一个组件占用内存过多，导致整个应用无法接受处理客户请求，这有可能出现，但在微服务里这是不会出现的。

　　丰富的技术栈。今天很难用一种语言开发某一种应用，今天应用可能是用不同的语言来开发的，因为不同语言开发的效率不一样，所以将来微服务的应用可能有很多语言，所以对语言来说没有要求，都可以选择合适的技术栈。

　　提高组织效率。每一个微服务是由一个小的team去维护、开发的，所以如何打造高效的小型团队，5-6个人，这也是非常重要的。

　　智能云架构：How？

　　业务域&技术域。服务要建模，服务要划分，这部分与业务视角相关，一定有业务含义的单一职责原则实现的微服务拆分。如果感兴趣的话，有微服务驱动设计，可以看一下，教你怎么按照这种原则拆分你的微服务。

　　技术域。微服务框架目前市面上已经有的Spring Cloud/Dubbo，微服务其实并没有限定用哪种语言，如果用的是支撑平台，对语言没有限定，支撑平台可以选定哪个，容器方面可以选择Kubernetes和Docker，货币宣传一个PaaS平台，就是AKS，或者OpenShift也可以。当然基于IaaS平台也可以，要自己动手搭建。

　　组织域&技术域。微服务会导致开发效率低下的话，这个微服务是没办法迭代起来的，要求每个微服务开发周期比以前要大大缩短才可以，随时测试、随时上线、随时部署，要求有一个DevOps平台帮助你支撑这些。

　　以上是实现微服务架构的思路，供大家参考。

　　二、Kubernetes与微服务架构

　　Kubernetes核心组件。

　　回顾IT发展，最近五六年比较激动人心的三大技术架构里，底层基础架构、计算网络存储、容器产生以后，归类为基础架构层面，所以在基础架构层面出现了Docker，以及Kubernetes技术，这是革命性的。

　　Kubernetes迭代发展到现在，目前组件是有增长趋势，所以可以在论坛上看见有人说Kubernetes越来越庞大了，它虽然庞大，但核心基本没有变，那些组件可以加，也可以去掉，并不作为核心组件加进去。

　　前面说到弹性扩展怎么保证？如果一直保证持续运营这些任务有DeamonSet，如果运行一次任务有Job这些的对象帮你做。

　　要自动扩展有一个Horizontal Pod Auto-scaler。Service，因为后台是很多个容器实现的服务，怎么找到这些服务呢？用的是service。

　　外部负载均衡怎么找到？Ingress，可以自己去定义你的路由规则。对于什么路由规则，怎么路由到service的规则，很灵活。

　　Secret，用户名、密码可以保存在Secret，既保证安全性，又保证了便携性。除了用户名、密码，还有很多配置信息怎么办，不能也写死在容器里，用ConfigMap帮助你实现。还有一些特别的权限，比如在容器里，这个容器里的这个服务需要访问其他容器里的其他服务，需要授权，用Service Account，这是访问内部授权的账户。容器如何实现持久化，用PVC和PV去实现。这些都是Kubernetes帮助你去做的。

　　如何帮助做到这些事情？这些事情都是你在做微服务这个平台需要考虑到的，这些东西Kubernetes已经帮你做了。Kubernetes基本上已经可以作为一个比较适合支撑微服务的架构平台。

　　前面说了“基本上”，为什么？因为Kubernetes必须是容器云的平台，并不是为微服务而生的，是微服务这个架构越来越火了以后，大家想Kubernetes能不能作为微服务的支撑平台，就加了一些能够支撑微服务平台的特性，但还不够，因为毕竟不是为微服务而生的，是为容器而生的。所以就出现了Service Mesh，可以理解成是一个容器服务，这个容器是做什么用的？绿色方块是每个容器，蓝色方块是Sidecar，也是一个容器服务。容器之间所有服务都要经过我来帮助你去通信、流量管理、限流等杂七杂八的活，都帮你干了。因为在Kubernetes平台里没有这些东西，那些是微服务平台要求的。

　　Service Mesh迭代非常快，蓝色小方块是Sidecar，有一个控制面板帮助你去管理，这是它的原理。Service Mesh是一个可以部署在Kubernetes上的容器服务，也就是说Kubernetes+Service Mesh就可以最终成为一个微服务强有力的支撑平台。

　　Service Mesh是一个理念，是一个概念，真正实现它的是Istio，Istio目前迭代到1.2版本，实现的理念就是前面说的这种方式。把Istio部署到Kubernetes上，就有一个完整微服务的支撑平台。

　　三、AKS支撑微服务架构

　　Kubernetes已经支持微服务架构了，但还不够，为什么？Kubernetes周边还有安全、治理、认证、底层架构Automation，还有开发相关、监控相关等，在Kubernetes上没有。对于很多第一次接触Kubernetes的人，看到它的安装手册或学习手册，可能都会被吓到，因为安装一个Kubernetes就要花好几天的时间，还是比较顺利的情况下。所有的云厂商都有一个目的，即致力于把复杂问题让你易于上手，AKS就是这样一个产品。

　　如果DIY  Kubernetes，如果用托管式在Azure上的Kubernetes，容器化基本是一样的，都可以，没有问题，应用的迭代和debugging在上面是可以的，CI/CD直接可以集成到你的DevOps平台。Cluster hosting是托管，我帮你托管整个业务服务，因为升级很有可能需要现场职守，还有备用方案，万一升级失败怎么办，这里我们帮助你自动升级。Scaling，一个是容器本身自动扩展，这是Kubernetes本身提供的，另外这里Scaling指的是底层计算资源一个节点，如发现这个集群大小不够，需要再增加几台机器，如果用手工去做比较麻烦，在这里可以帮助你做自动化，只需要一条命令就可以。日志和监控已经集成进去了。

　　Kubernetes分管理节点和计算节点，管理节点一般是单数，1357，master节点，这些节点本身是虚机，要收费的。但在这里因为是托管式的，所以管理节点免费，只收计算节点费用，这是非常合理的。我们对上面还是坚持支持Kubernetes100%的兼容，唯一改的是把这一块改成了由我们来托管你的master节点。

　　AKS如何快速创建一个Kubernetes集群（Demo）。

　　出现一个界面，因为我们所有资源放在一个资源组里，新建一个资源组名字就可以了。现在区域是在中国北京北2和上海东2两个数据中心可以部署Kubernetes集群。

　　版本可以自己选，默认是1.7，现在到了1.14。底下选虚机大小和个数。

　　可以选择网络，一个是基本网络，一个是高级网络，基本网络你不用管，自动按照默认帮你设，高级网络是你自己设定一个局域网，把Kubernetes部署到你这个局域网当中，可以自己设定一个网络规划，把Kubernetes部署到你的这个网络当中。

　　创建，根据选择虚机的个数和大小有一定关系，大概10分钟会创建完毕。创建好集群以后，有访问地址，可以看到所有资源信息图表的监控，可以看到集群，有多少节点，目前有3个计算节点，可以把它点开来看，可以看到目前跑了哪些服务，可以看到容器具体信息。

　　如果想升级，点一下升级，就可以升级到当前最新版本。

　　扩展，点击扩展节点的大小和资源。

　　日志，非常重要，因为把应用部署到容器化以后，怎么看到每一个应用的日志，把所有日志收集到一起，展现在一个平台上，可以按照关键字去搜索。

　　四、Azure DevOps加速微服务

　　微软现在云上有Azure  DevOps的服务，这是公有云上的服务，还有私有云的服务，可以部署在私有云上。

　　有五个功能组件：面板，可以看到所有工作量信息，以及跟踪你的工作进度；管理原代码；做CI/CD的地方，Pipelines；做测试，主要集成测试或负载测试；Artifacts，存储二进制打包的东西。这五个组成在一起就是端到端完整的解决方案，可以选择适合的工具，开源都可以在上面去跑。

　　（图）AKS+DevOps加速微服务应用迭代。整个过程是自动化的。

　　我的演讲就到这里，谢谢大家！