融数数据基于DevOps的微服务架构演进之路
— 中生代技术嘉年华 —
2017.3.18，中生代技术嘉年华在成都盛大召开，6大主题、20话题同时在3个场馆同步进行，相信来了现场的小伙伴们都有过不能同时在3个场馆听现场的纠结，因故没来现场的更想知道现场的盛况和内容，我们将会陆续将各话题整理发布，让大家共享这场技术盛筵。
中生代技术嘉年华成都纪实（一）和中生代技术嘉年华成都纪实（二）中可看到更多照片和话题汇总。
主题：互联网架构
融数数据基于DevOps的微服务架构演进之路
- 融数数据CTO 王东
讲师介绍
王东：
现任融数数据北京研发中心CTO，负责公司大数据平台、微服务框架以及DevOps平台的研发工作；
毕业于天津大学，毕业后一直从事软件相关研发和架构设计工作，曾经在普元软件任资深架构师、IBM GBS任咨询经理、亚马逊任架构师等，后加入创业公司，从事研发和管理工作；
热爱编程，喜欢钻研新技术，对于微服务、企业架构、大数据以及DevOps有浓厚的兴趣。
谈谈微服务
近年来微服务热度逐渐增加，从Gartner 2016年技术hyper cycle图上可以看出，微服务是目前非常流行的技术，从amazon，google，facebook等大型互联网公司到一些传统企业，都在采用微服务架构。
那么，微服务到底是什么？
“Microservices are loosely coupled service oriented architecture with bounded contexts.” (Adrian Cockcroft, Netflix)
微服务应该尽量避免对通用组件或者基础构建块的依赖，例如数据库；
Bounded context来源于DDD，其提供了一种将大型架构拆分成具体feature的方法，真正的微服务希望团队无需过多地了解其他微服务团队的业务知识。
微服务与SOA有什么区别？
微服务架构依旧遵循SOA的设计原则
微服务架构强调敏捷、独立开发、独立部署、独立扩展，“小”不是微服务的判断标准：
一个服务只实现一个独立的Feature
尽量不要为外部应用发布代码级API，依赖通过服务调用或者事件搞定
服务之间最好通过异步事件交互 每个服务拥有自己独立的数据
微服务与SOA的对比
融数数据微服务架构
融数微服务架构选型思考的几点原则
选型过程中，我们比较了流行的开源框架
构建融数微服务架构，希望得到什么?
因此，我们的选型经历了如下过程:
融数微服务架构总览
融数微服务架构之服务端 – Graeae Endpoint
Graeae是一个协议无关的服务框架
对GRPC进行了封装，优化了GRPC代码生成的结构，调用方式，并采用同步方式简化GRPC调用和实现的基于Oberserver的异步调用
增强了GRPC的LifeCycle，添加了服务注册，基于zipkin的调用链等功能
重构了gRPC框架生成的Stub的结构，解耦和Stub，消除了基类继承
添加了Graeae框架的Spring Starter，简化了服务启动和客户端调用
融数微服务架构之端点 – Graeae Endpoint
抽象基于生命周期的服务容器概念，将服务运行时划分为生命周期的各个阶段，在生命周期的各个阶段完成对服务上下文的构建与管理
提供对服务端治理的注册、寻址支持
提供对部署层的代码、配置分离
底层基于gRPC，在gRPC基础上对易用性及功能性进行加强：
\基于annotation标注及stub重新构建，打断业务实现与gRPC的紧耦合
重构stub，简化方法调用，屏蔽gRPC stub易用性间隙
客户端增加熔断器，增强应用容错 其他部分增强，如支持zipkin
融数微服务架构之服务代理 - Proxy
融数微服务架构之服务治理 – 基于Proxy的服务端治理
Proxy是Client访问的端点
Proxy负责服务实例的信息收集和注册
基于Proxy的路由功能结合语义化版本(X.Y.Z)的概念进行不同服务的版本管理
利用Docker简化部署 利用Proxy绑定VIP来简化客户端寻址
融数微服务架构之服务调用链
基于开源zipkin构建
分析服务调用关系，绘制运行时拓扑信息
衡量成功率／超时信息
为服务扩容／缩容／降级／流控等提供数据参考
与运维监控平台结合，发送服务报警信息
微服务架构之基于Pinpoint的APM监控
gRPC探针
服务调用链拓扑
调用链监控
与告警平台整合
利用报障平台跟踪改进
微服务架构的未来规划
Transport多协议接入
通过Proxy将gRPC协议转换成Rest服务
基于Web的脚手架工具
利用Pinpoint替代Zipkin，更加精细化的服务调用链监控
多语言支持，计划支持Node.js， Python和Go
我们是如何一步步实施微服务的:
从单体应用或者传统分层架构的应用想服务化过渡，通过封装和组合等方式，提供对外发布接口的能力，从而提升应用的可访问性；
通过重构将domain-level的功能模块转变为可以独立部署的服务，从而提升整个应用的敏捷性；我们称之为miniservice，其粒度比微服务粗（domain level），因而抽象的难度比较低，但是也能在一定程度上获得微服务所带来的敏捷性提升的好处，但是对DevOps的基础设施等要求也没有微服务高
通过Feature-Level的抽象，根据单一职责原则将miniservices差分成微服务，从而获得更高地扩展性和敏捷性
独立的数据可以使独立数据源或者独立
拥有了一套服务开发框架，我们就拥有了微服务？
微服务与DevOps
微服务为什么需要DevOps?
微服务的主要目的是为了敏捷
微服务表达了原子核心业务（Feature），但是也带了新的挑战-将单体应用的复杂性从程序内部转移到了服务组件之间
因此，根据Martin Fowler提出的观点，微服务需要具备以下三个重要能力：
硬件资源是否能够快速到位 – 环境管理的能力
是否具备了微服务监控能力 – 分布式监控能力
是否具有快速的开发部署流程 – 敏捷成熟度和自动化程度
服务粒度的细化，导致团队间的合作和沟通变得困难，当发生问题时，我们希望问题快速的暴露并得到迅速的解决，而DevOps是开发和运维团队的粘合剂，能够促进合作，提升解决问题的效率。
那么DevOps是什么？
DevOps works for startups, but enterprises need it more.
对于DevOps文化，从全栈小团队说起
康威定律
Two-Pizza Team
如何划分小团队，团队间怎样协作？
团队切小后，我们按照业务线对组织进行架构，以便技术团队能够专注的解决对应业务的问题（业务驱动，或者说业务优先）
这时，团队内部的设计决策，将在团队内部消化，因为团队的规模已经是7+/-2人的量级，一般情况下不会有特别负责的工作。
但团队增多后，团队的协调将是一个问题，因此，微服务从技术上帮助团队所负责系统的解耦，而计划流程有帮助团队在工作安排上找到合理的步骤
那么，当一个大的业务被分解到各个小团队时，还是会有跨团队的设计工作，以上两点是要严格执行的。
技术团队和业务团队的合作并非经由上层协调，双方主要的沟通都是团队之间直接的水平沟通，也就是说：
在最底层的团队之间，需求、问题和日常交流都是直接由业务团队反馈给技术团队的经理。
而问题的解决容许业务团队直接接触开发人员
另外，水平的沟通发生在业务和技术团队的各个层面上。
向上的汇报机制用来反馈问题和业务的进展情况。
我们提倡什么样的团队文化
主人翁意识（Ownership）
行动力（Bias for Action）
吃自己的狗粮（Eat your dog food）
工程师负责从需求调研、设计、开发、测试、部署、维护、监控、功能升级等一系列的工作，也就是说软件工程师负责服务的全生命周期的所有工作
运维是团队成员的第一要务，在强大的自动化运维工具的支撑下，软件工程师必须负责服务或者应用的 SLA
让开发人员参与架构设计，而不是架构师参与开发
研发人员是Owner，对业务和团队负责
强调抽象和简化，将复杂的问题分解成简单的问题，并有效解决，防止过度设计
鼓励用新技术解决问题，但强调掌控力
融数如何利用DevOps平台构建微服务
打造融数数据卓越运营平台
建立高效的开发+运维的生产和反馈闭环
围绕智能报障的自改进生态
构建相互支撑的整个系统生态+流程
逐步构建卓越运营体系
遇到问题，迅速跟进、快速解决
定制 SLA
7X24轮值
时效监控
多渠道通知
上报机制
想观看现场视频，可从下图二维码进入