陈屹力：感谢主持人，再次感谢今天下午到场的各位嘉宾，今天下午的议题是一个标准解读，同时也是微服务标准历经了大概半年时间正式发布，目前标准正在征求意见阶段，后面我们再同步跟进送审稿，最终发布大概在9月份，待会儿我会详细介绍。
今天主要的内容分四个部分：
一是微服务的概述，描述一下微服务在国内的情况，包括技术趋势。
二是微服务标准制定方面，做一些简要的概述。
三是围绕云计算一些关键技术领域的标准化评估工作。
四是未来我们的工作计划和下一步的安排。
首先说一下微服务的定义，微服务的定义公认的是ThoughWorks公司的Martin Flower的博客描述，从他们官方的微博里可以看到微服务架构采用一种小服务来构建应用的方法，每个服务是独立运营，各个服务之间靠标准的RPC或者HTTP进行通信。最重要是服务围绕业务本身去构建，并依赖自动部署机制来独立部署。
大家知道应用架构的整个演变过程，从单体的结构更多的是向集中架构发展到分布式架构，再到微服务架构。集中式架构就是一个War包或者其它形式的格式，发布、运行就可以了，对于资源或者消耗是相对比较少的。二是在维护方面是统一的，哪怕是一个很小的更新也要整体打包发布。
分布式很大程度是解决性能，二是解决高可用的问题。
到微服务，整个粒度变得更小了，通过组件化去独立开发和部署，大大有利于应用局部的快速迭代。微服务架构的特性是随着更新迭代的敏捷性，它的需求不易维护和难以扩展，其实是整个单体架构很大的一个挑战。目前云计算、大数据这种越来越庞大的体系，其实传统架构很难去适应新的业务需求。微服务就是在当前这个容器技术非常成熟的情况下，微服务我觉得是一个面临一个变革的趋势。
在他们总结微服务架构的时候也同时给出了微服务的设计原则，通过服务组建化围绕业务能力组织、产品，而非项目化模式，去中心化的治理和管理模式，智能端点和亚管道，技术人员是更多偏向无状态，智能端点更多是在服务端和消费端。故障设计包括熔断、限流这些设计。演进式设计，微服务是慢慢逐步迭代、逐步演进的过程。最后的基础设施，尽可能的让基础设施IaaS层实现自动化，自动化类似于编排能力。
微服务并不是说一个彻底的创新，之前不管MVC架构还是SOA架构是一个发展阶段，SOA和微服务架构粒度是不一样的，微服务的边界是很难定义的，没有一个统一的边界。在服务架构里，SOA大的特性是企业总线。相对来说它还是集中式的架构，对微服务分布式的架构，它是一个去中心化的架构。SOA按照模块服务规模相对是比较小的，到微服务拆分的粒度更小的话，逐步的应用的规模是在不断扩充。重复式模式，业务是相对低的，独立微服务里面是高并举。
微服务的优势可以体现在几个主要的方面，每个服务都是比较简单单一的，只关注于某一个具体业务功能，而且微服务可以提高更高的灵活性，所谓这个灵活性哪怕你今天一是个单体架构，那么你可以用微服务架构去实现，不断去扩充再去迭代旧的。
微服务可以通过不同的编程语言，就是说它是跨多语言支持。微服务的开发和维护，是可以有一个独立的团队和组织去提供，这样的话便于扁平化管理和快速的响应。微服务架构有利于CICD的实现。
说完微服务架构的优点，缺点也很明显，我们怎么样去平衡需要在座各位去思考的问题。首先运维成本增加，粒度的减小带来应用的示范提示是倍增的。微服务架构上的复杂性，微服务和微服务之间这种关联越来越复杂，怎么样管理，这是一个很大的挑战。
第二个是人员技能要求比较高的，至少熟悉DevOps基本技能。
第三个是微服务之间的依赖是有明确的定义。
第四个是团队的协作上会出现一些问题吧，难免会在代码重复这个问题上有一些重叠的。
架构的复杂性，特别是跨部门、跨域的情况，分布式架构一定要考虑到很多因素，所以在架构方面也是需要多多考虑。
下面是说机制的风险，应用存在这种跨微服务的事务性处理，分布式不仅仅是微服务的问题，而且是整个分布式架构的一个问题。对于一致性的要求是怎么样的，是强还是弱，还是最终的一致性。
可测性比较差是微服务里比较凸显的，因为正常的应用开发，大家做单元测试都是很明确的，功能模块去实现单元测试，但微服务里面这个测试起来是相对比较难的，基于微服务架构变得相对复杂。
微服务架构和技术框架这一块，我罗列了几种。像知名度比较高的这几种，（见图），这个就不太多介绍了。
对于微服务架构平台和服务来说，我们可以考虑基于这种微服务架构，市面上提供微服务架构的厂商或者云服务或者私有云产品有哪些。阿里云，腾讯云、华为云、天眼云都提供线上微服务平台，国外对标的AWS和微软。微服务平台像灵雀等，他们都提供。
微服务架构的设计原则，在我们做这个标准的时候也考虑到了，能不能在两个行业里给大家一个最佳实践，其实thoughtwork公司也给了一个设计的准则，但我们想能不能在面向国内的产业里，或者国内用户，因为毕竟不同行业面临的对标不一样。比如金融行业的监管要求，还有其它行业的，像电力、能源对安全的要求还是挺高的。我们在设计原则的时候可能是更偏于业务和管理，后面是微服务目前相对来讲，相对容器类的PaaS平台来讲，国内落地还是相对少的。所以我们后面通过不断的积累真正形成一个行业的最佳实践，然后分享给大家。
这是微服务架构需要平衡的几个问题，这是伸缩立方，总结的应用水平货栈和应用微服务化和数据分区这三方面的权衡。后面是业务拆分需要微服务架构需要考虑的方方面面，包括人员、模块之间的切分边界在哪里，包括安全、运维等方面的因素都要去考虑。
首先讲一下标准化的意义和必要性。微服务是一种将应用解耦的，常见的微服务框架，在不同的技术，技术没有好坏，但在实现上或者技术路线上有很大的差异，我们大概总结去对业务尽可能的减少依赖。这两种方式，对于用户来讲我怎么选择，对于产业来讲还有技术生态的问题如何选择。
国外我们也找到一个ITU的标准，国内暂时没有。国内在我们立项的时候只有这么一个标准，非常巧这个标准是中国电信在ITU立的项。
标准的起草实际上是在2017年底开始筹备，已经内部讨论过很多次。2018年4月份在厦门正式起草了一个标准文稿。首先这个标准是两个标准一起走，团体标准和行业标准是同步进行的，立项是同步进行的，但做的时候是分开的。因为CCSA有它的标准和节奏，流程相对是比较严格的。所以我们在4月份起草的标准文稿，先做团体标准，经过了线下六次研讨，和几次线上研讨，今天形成的征求意见稿，9月份发布最终稿，也在那个时间前中间希望各位多给我们提意见。同时在TC1GW5标准租进行标准立项，正式通过立项申请，9月份应该是征求意见稿。
进入到今天的主题，微服务平台的一个架构的参考模型。标准基本上是按照逻辑关系构建的，这个图看起来简单，但是我们讨论了不下20次，改来改去。整体分为几块，首先底层还是对于微服务平台来说，底层的IT基础设施，我们认为还是必需的，但不是重点。因为底层的IaaS是提供商层微服务平台的重要支撑。第二层是一些公共技术服务，就是提供微服务架构的一些通用而且必要的，才放到这里。
上面是微服务架构的核心，我们总结了微服务架构的必然能力，之外我根据不同考虑不同的场景和技术路线增加了一个增强特性，我们建议去引导整个产业，逐渐的拔高，但作为目前的阶段它的要求实在是稍微有点高。最后是作为一个管理平台要能管理你的微服务，拥有对底层资源的监控，这也是必要的。看着内容不是很多，但也是我们最终讨论了很久才有这样的结果。
下面根据架构图分别将一下对每一层具体的要求和想法。像基础设施是针资源管理、编排能力、部署方式有一些要求。监管，对底层物理，底层资源对上层尽可能透明，这样对一些定位或排查错误的有效手段。编排能力，指针对资源的编排，尽可能是可视化的编排方式。部署方式，私有云的场景下，能自动化的帮他部署，这样能节省交付周期。
微服务框架的能力要求，大概有10个指标，其实11个，后面的安全服务健全放到总体安全要求里面去了。大概介绍一下就可以了，多语言支持，这是微服务里面强调的，语言无关性，尽可能支持两种或两种以上。服务通讯可以支持标准的RPC，或者SDP包括自定义的通讯协议。服务注册，自动支持自动感知。服务发现也一样。服务注册，是能自动发现服务，在自助中心完成注册。服务发现，启动服务，自动中心能自动被感知。流量控制，在流量做一些适当的QOS的控制。负载均衡能按照权重、人群。服务契约，我们希望有一个能支持微服务统一的接口描述，符合Open1的规范。服务容错，依赖服务出现的故障能自动半自动的在业务层面实现平滑的处理。服务熔断对故障节点的快速转移或者失败转移，停止服务，隔离能至少支持进程级的故障隔离。
公共基础服务能力，支撑平台不可或缺的一些服务。APM对应用之间的性能或者一些关键指标起到量化的作用，这样方便运维层面管理。服务网关，大家知道微服务里面有一个很重要的是服务网关，基于规则、路径、协议、转发等实现服务自动发现、服务调用。
增强特性是两个指标，一是故障输入，二是分布式事务，分布式事务是根据用户的需求或者要求去实现基于分布式架构的分布式事务的比如强一致性、弱一致性，和最终一致性。
故障测试是在上线之前做的故障测试的一个手段，便于你处理一些应急或不可预知的一些错误。
管理平台，这几个就不介绍了。包括流水线，流水线就是整个对于微服务来讲，需要具备的一些管理能力。
服务降级能保证核心业务在一旦出现故障，降低非核心业务的一些服务质量。
性能要求，其实我们在标准里面是不便于提出来对性能方面的一些要求，但我们在讨论这些事情的时候，是说不同的通信协议、技术路线和优化方案，对于它的性能是有很大影响。那么我们是不是可以提出来几个指标供行业里面去参考？比如说你去固定统一的资源配置去验证它的性能，这是我们想强调的，并不是说我们要要求什么样。后面我们逐步的，比如在行业里面有一个评估的手段来了解整个行业的平均水平怎么样的，就可以列出什么样的情况下，它的性能要到达一个合理的区间。
安全能力要求，一是通过TRS或者证书的方式去鉴定它的身份。二是它有没有权限去访问，进行服务调用。
配置加密，对于配置管理，难免会遇到一些比较敏感的数据，通过手段去保证数据的私密性。
下面说一下软件产品标准化和一些成果。我目前主要工作是在软件产品，也就是私有云或者面向云计算通用的关键技术的解决方案和产品一类的标准。2016年7月做了一个开源解决方案，2017年6月份做了一个容器的，到今年做了一个微服务平台，目前是三个标准。
我们标准在国际化上，2018年3月份跟CNCF做了一个国际对标，也就是深度的合作，双方认可各自的标准或规范。我们知道CNCF是有一个一致性认证的，我们做了一个双认的，最后起名TCCK，主要是针对容器的。本来之前是三个，腾讯云、网易云和中兴，今年增加了两个，博云和灵雀云。
我们在微服务的正式稿发布之前征求微服务的评估标准，行业标准也在同步跟进，下一步着手微服务平台的评估工作，进一步深化微服务在行业中的一些应用。
第三个，也是跟我的工作相关，持续跟进关键技术的标准化进展，可能下半年会同时启动共有云行业的标准制定。
最后，我们在国际上的合作还是更加深入一点，就是跟国际的组织或者开源社区加强合作。
最后感谢这个标准的核心编写单位，（见图），中国信通院牵头，华为、腾讯、博云、希云、中国电信、H3C等等。我们今天请来了几位核心编写人员，今天在场的有4位，同时感谢名单里面的核心编制人员。
热门专题
