内容简介
- 谈谈微服务
- 微服务技术选型过程
- 微服务架构设计的一些思考点
- 融数微服务架构的核心概念和实现
- 融数DevOps平台对微服务的支撑
- 技术团队的组织
- Operation Excellent
谈谈微服务
微服务与SOA的异同
- 从设计原则来讲，微服务架构遵循SOA principles
- 小的、可重用的服务并不一定是微服务，微服务架构强调敏捷、独立开发、独立部署、独立扩展，重用在某种程度上范围影响
- 敏捷性
- 微服务架构为了实现其敏捷特性，在SOA约束的基础之上又添加了新的约束
- 微服务之间不能互相依赖，因此要求微服务能够独立部署，独立扩展，微服务之间的依赖越少越好
- 一个应用只做一件事
- 不要为外部应用发布API，依赖通过service或者事件搞定
- 最好通过异步事件交互
- 每个应用拥有自己独立的数据
微服务技术选型过程
- 目前团队主要采用Spring Boot + RestEasy的方式实现服务化
- 首先支持rest
- 现有业务代码的迁移不希望改动太大
- 小团队，希望能够有一个比较全面的解决方案
- 结论
- Netflix提供了比较全面的解决方案
- Spring Cloud对于Netflix的封装比较全面
- Spring Cloud基于Spring Boot，团队有基础
- Spring Cloud提供了Control Bus能够帮助实现监控埋点
- 业务应用部署在阿里云，Spring Cloud对12factors以及Cloud-Native的支持，有利于在云环境下使用
融数微服务架构的核心概念和实现
核心模型
- Shapes （定义数据类型）
- Simple
- List
- Map
- Structure
- Traits （定义Shaps的行为）
- Spring Cloud
- 遵循12 Factors
- 模式
- Configuration Management
- Service discovery
- Circuit breakers
- Intelligent routing
- Control bus
- One-time tokens
- Global locks
- Leadership election
- Distributed sessions
技术团队组织 – 结果导向
- 主人翁意识（Ownership）
- 行动力（Bias for Action）
- 吃自己的狗粮（Eat your dog food）
- 工程师负责从需求调研、设计、开发、测试、部署、维护、监控、功能升级等一系列的工作，也就是说软件工程师负责应用或者服务的全生命周期的所有工作
- 运维是团队成员的第一要务，在强大的自动化运维工具的支撑下，软件工程师必须负责服务或者应用的SLA
- 让开发人员参与架构设计，而不是架构师参与开发
Operation Excellent
分享者简介：王东现任融数数据北京研发中心CTO，负责公司大数据平台、微服务框架以及DevOps平台的研发工作；毕业于天津大学，毕业后一直从事软件相关研发和架构设计工作，曾经在普元软件任资深架构师、IBM GBS任咨询经理、亚马逊任架构师等，后加入创业公司，从事研发和管理工作；热爱编程，喜欢钻研新技术，对于微服务、企业架构、大数据以及DevOps有浓厚的兴趣。
