微服务设计概览

最近看完了Sam Newman的<微服务设计>这本书,数据从整体上介绍了微服务设计的各个方面,这里罗列了一些内容概览,不得不承认,国外的技术人员理论知识是真的扎实,知识面也相当全面,有需求的推荐看一下这本书.

微服务价值:

1 技术异构性
2 弹性
3 扩展 gilt 在线商城
4 简化部署
5 开发运营与组织结构相匹配,沟通成本低
6 可组合性
7 可替代性

服务拆分:

SOA(Service-Oriented Architecture):面向服务架构

共享库:共享代码抽取为单独的库.提高复用性;缺点:不支持异构;更新时需要重新部署服务;

模块:有一点的隔离性,但是时间越长调用的耦合会越严重.OSGI(Open Source Gateway Initiative)开发服务网关协议

服务建模:

好服务:高内聚,低耦合

限定上下文:是服务的实际边界,划分便捷可以通过模块的方式进行区分,等服务稳定后将模块分离成独立的服务.
参考资料:<领域驱动设计> Eric Evans
         <实现领域驱动设计> Vanghn Vernon

服务集成:

原则:
    避免破坏性修改.修改内容不能影响原有功能;
    保证API的技术无关性;
    服务易于消费方使用;
    隐藏内部实现细节;
    
服务接口

同步异步;    
    异步:回调;事件
    
编排与协同:编排是中心控制点,指挥下层服务调用;协同是事件订阅,下游服务同时处理;

服务调用方式:如SOAP,XML-RPC,REST,Protocol Buffers等
    参考资料:REST实战
    
基于事件的异步协作:
    消费者接收事件机制:MQ
    
    微服务发布事件机制:ATOM

异步模式的复杂性:参考资料<企业集成模式>    

版本管理

服务分解:

分解的价值:
    改变开发速度
    适应团队结构
    独立部署与运行,服务更安全
    更新技术实现

分解方法:
    1 识别服务边界上下文的缝隙;
    2 通过缝隙将修改时逐步把同一关联变化聚合在一起,逐渐实现内聚性.
    3 共享依赖问题
        a.外键依赖,通过接口来调用服务,而不是直接去操作数据库
        b.共享静态数据(邮政编码等不变的数据)通过配置文件或静态代码来实现.
        c.共享业务数据,补充抽象模型,让业务模型更完善.如仓库,财务都需要查看订单数据,
            而订单对应的其实是用户模块,这里应该增加用户模块,通过接口返回外部依赖共享的数据.
        d.共享表一些还需要进行细粒度拆分,实现交叉业务的分离    
    4 事务.业务中保证业务的一致性很重要,但是服务拆分后,本身单一事务也会被拆分为多个分离的事务.事务处理方式:
        a.重试,某一事务成功,但是其他事务失败是,通过重试来实现最终一致性.
        b.终止业务.通过补偿事务抵消之前操作,如果抵消还不行就需要后台管理实现人工操作的方式,简化事务的操作.
        c.分布式事务.两阶段提交:投票和提交两个阶段.
        实际处理中应避免分布式事务,如果存在则首先要考虑微服务模型是否可靠,是否应该将部分服务整合;
            其次是抽象出事务流转状态,将本身应一次性实现的多个服务阶段分离成单独的服务阶段,
            拆解事务,只需要操作流转,就可以实现最终的一致性.
    5 报表问题.实际报表可能需要多个服务的数据才能生成.实现方案如下:
        a. 增加独立报告数据库,进行数据汇总;
        b. 跨服务调用,获取数据
        c. 数据导出后文件汇聚到独立数据库中
        d. 事件触发数据同步到独立数据库中
实际的缝隙可以是代码的命名空间,如java的package.           

部署:
持续集成.
持续交付:构建流水线
软件环境自动化:Puppet,Chef,Ansible
服务环境自动化:定制化镜像;配置漂移:部分环境因为手工修改,造成环境不一致的情形;

服务与主机的映射:一台主机应部署多少服务?
    单主机多服务:
    应用程序容器:tomcat,一个部署服务可以运行多个对外服务
    单主机单服务:
    平台即服务(Paas):
    物理机到虚拟机:
        标准虚拟化:hypervisor隔离服务环境.传统虚拟机方式;Vagrant
        共享操作系统内核:
            Linux容器:LXC
            Docker

测试:
<敏捷软件测试> LisaCrispin

单元测试:
服务测试:
端到端测试:

测试工具:Pact

监控:

单一服务,多个服务器:Nagios

多个服务,多个服务器:
        
日志:Kibana;

多服务指标跟踪:Graphite

关联标识:Zipkin

级联:Hystrix

标准化:日志格式,接口格式

未来:Omniture
    Riemann
    Suro

安全:

身份验证
单点登录:
网关:Shibboleth
细粒度授权:

服务间认证授权:
    内部可信
    https
    SAML,OpenID Connect
    客户端证书
    HMAC,基于哈希的消息码
    API密钥
    代理问题
    
静态数据的安全:
    使用通用加密算法
    密钥管理:
        单独的安全设备来加密和解密数据;
        单独的密钥库,需要时访问获取,密钥生命周期管理;
    数据安全等级划分;
    按需解密;
    加密备份
    
深度防御:
    防火墙
    日志:检查是否有异常操作
    入侵检测系统
    网络隔离 vpn
    操作系统,定期打补丁;
    减少不必要信息获取,降低维护成本
    人的因素
    使用通用加密方式,不要自研
    内建安全,安全团队
    外部验证

规模化微服务:
故障无处不在
服务需求指标:
响应事件/延迟:每秒处理200个并发连接时,90%的响应时间内在2秒以内;
可用性:24/7,测量停机时间,只能从历史报告的角度有用;
数据持久性:多大比例的数据丢失可接受?数据要保存多久?

功能降级:

架构性的安全措施:设置请求超时;实现舱壁隔离不同连接池;断路器;
反脆弱的组织:定期或不定期模拟宕机,看服务可用性
    超时:
    断路器.
    舱壁
    隔离:运行下游服务离线
幂等:重复操作,不影响最终结果
扩展:
    纵向:增强主机
    横向:拆分负载:
        分散风险
        负载均衡
        worker:队列模式,多个消费者抢占消费;
扩展数据库:
    持久性和可用性
    扩展读取
    扩展写操作:Cassandra,Mongo,Riak
    共享数据库基础设置:schema
    CQRS:命令查询职责分离.
    
缓存:加速响应,保护实际数据源
    客户端:减少网络请求,降低下游负载;过时数据失效比较难;
    代理:Squid,Varnish.简单;但会增加额外的网络跳数;
    服务端:直接控制缓存失效;跟踪和优化缓存命中率;
    HTTP缓存:
    为写使用缓存:排队,保证后端服务的请求稳定
    弹性使用缓存:定时获取缓存数据,以避免服务不可用;
    隐藏源服务
    
自动伸缩:

CAP:

服务发现:
    DNS
    
动态服务注册:
    Zookeeper
    Consul
    Eureka:
    
稳定服务
    Swagger