微服务架构 2019-04-15

微服务不是一个纯粹的框架或技术，而是一个综合性的架构模式。
技术具体讲就是分析、设计、建模、落地实施方法。

微服务与DDD

Domain Driven Design 领域驱动设计
DDD是一种以领域为核心的设计和开发理念。

表示层 MVC MVP
应用层
领域层领域模型
基础设施层

精简的业务知识
业务需求和技术实现之间的桥梁
解构业务真实需求

微服务与GRASP

General Responsibility Assignment Software Patterns 通用职责分配软件模式
核心：职责分配

基本原则
信息专家
创建者
高内聚
低耦合
控制者
多态
纯虚构
间接性
变化预防

微服务与RUP

微服务与SOA

IT建设以部门级为主。
竖井应用
从关注部门需求到关注企业需求，需要部门间数据共享、业务共享、客户共享
组织与业务流程频繁变化

SOA解决的问题
信息孤岛互联互通业务重用

区别
微服务不再强调传统SOA架构里面比较重的ESB企业服务总线
SOA思想进入到单个业务系统内部实现真正的组件化

共同点
服务化敏捷快速

微服务架构定义

微服务内涵

是由服务组件组成的系统
按照业务而不是技术来组织服务
做全生命周期的产品而不是项目
智能端点与通道扁平化
去中心化治理不必采用统一的语义与技术每个微服务可以考虑选用最佳工具去完成
去中心化数据管理分散存储与业务数据自治；倡导多样性持久化，采用不同的技术存储。
自动化运维（DevOps）自动化构建、自动化部署、弹性扩展
故障恢复与容错熔断机制；自动化监控/告警；日志审记
演化式设计

微服务好处

简单灵活，独立部署
小团队
松耦合，高内聚
与语言无关

设计原则

AKF拆分原则
前后端分离
无状态服务
Restful通信风格无状态通信

微服务应用平台目标

支撑微服务应用的全生命周期管理

微服务带来的问题

依赖服务变更很难跟踪，其他团队的服务接口文档过期怎么办？依赖的服务没有准备好，如何验证我开发的功能。
部分模块重复构建，跨团队、跨系统、跨语言会有很多的重复建设。
微服务放大了分布式架构的系列问题，如分布式事务怎么处理？依赖服务不稳定怎么办？
运维复杂度陡增，如：部署物数量多、监控进程多导致整体运维复杂度提升。

微服务的问题

企业IT建设的三大基础环境

我们先来宏观的看一下，一个企业的IT建设非常重要的三大基础环境：团队协作环境、个人基础环境、IT基础设施。

三大基础环境

微服务总体架构

服务注册和路由

注册和路由

安全认证

集中配置

静态配置和动态配置两种
配置与介质分离，配置不要放到Jar包里。
配置的方式要统一，格式、读写方式、变更热更新的模式尽量统一，要采用统一的配置框架。
需要有个配置中心来统一管理业务中配置信息。

分布式事务

可靠事件模式事务一致性
补偿模式 Confirm Cancel
TCC模式 Try Confirm Cancel

dubbo

RPC
Remoting: 实现了sync-over-async和Logo request-response
Registry:

Spring Cloud

docker

docker --help

jenkins

持续集成工具