基于微服务架构的技术实践

基于微服务架构的技术实践

对微服务的认识微服务架构实践总结与展望对微服务的认识架构由来常见误区微服务架构的出现/articles/microservices.html2012业务能力自动化部署终端智能语言数据分散控制基础设施自动化…微服务架构的演进史All

in

oneVerticalElasticMicro单块架构基本无人使用成本低，但二次开发困难垂直架构有一定模块化负载均衡SOA架构服务管控RPC技术微服务架构高密度部署原子、自治对微服务的常见认知误区0304微服务架构并不解决开发的问题，他更多强调的是一种风格，需要自己总结出最佳实践0102误区有人说按代码量，有人说按资源，还有人说按团队，都对，但是又不能以一概全这只是从内部服务间的通信上考虑问题，没有从扩展性、容错性、持续部署等维度考虑问题，何况微服务架构下，APIGateway或serviceBroker机制同样不可或缺微服务架构的推动与演进，切勿忽略各部门、不同角色的需求输入与能力支撑，要求很好的协作机制，要有及时的反馈与驱动微服务让开发变得简单微服务应该是按***拆分的微服务与SOA之间差了一个ESB微服务架构是***部门的事情微服务架构实践技术选型平台架构关键设计参考

->

平台的品质属性－＋－可用性＋＋＋＋－＋可测试性＋＋－＋健壮性＋－＋＋＋－＋－可重用性＋＋＋＋＋－＋可靠性－＋＋－＋＋－移植性＋＋＋－＋可维护性＋－＋－互操作性－－－－－完整性＋＋＋＋－－灵活性－－－－－－－－高效性＋＋有效性可用性可测试性健壮性可重用性可靠性移植性可维护性互操作性完整性灵活性高效性有效性用户属性：可用性（Availability）有效性(Efficiency)灵活性(Flexibility)完整性(Integrity)互操作性(Interoperability)可靠性(Reliability)健壮性(Robustness)易用性(usability)用户属性：可维护性(Maintainability)可移植性(Portability)可重用性(Reusability)可测试性(Testability)

参考

->扩展性立方体X:水平克隆Y:功能拆分Z:数据拆分XYZIaaSPaaSSaaS参考

->

12FactorSaaS构建原则标准化流程自动配置和系统划分界限环境适应性屏蔽开发生产差异化……重基础架构（平台）轻应用架构（服务）参考

->

BorgGoogle’sBorgsystemisaclustermanagerthatrunshundredsofthousandsofjobs,frommanythousandsofdifferentapplications,acrossanumberofclusterseachwithupto

tensofthousandsofmachines.经过验证的可参考技术栈VMContainerStorageNetworkService/AppInterfaceCross安全OpenstackCloudstackVMwareZabbixZenoss…DockerRKTKubernetescAdvisorJournald…CephGlusterFSCinderNFS…OVSFlannelNeutronSkyDNS…HystrixSpringBootEtcdSrvBrokerAPM…ESBAPIGatewaySwaggerMockserver…InfluxdbElasticSearchFluentd…可用性能开放50%25%15%10%需求匹配团队能力社区与厂商生态建设3过程思考

+

6关键能力概念模型建立设计原则数据说话容器资源的隔离与互通升级与回退服务注册与发现伸缩与漂移熔断与降级异构环境标准化过程思考(1)->概念模型建立ComputeStorageNetwork资源池VMContainer1*NFS1*Local…VLAN1*VxLAN…ServiceProcessPodReplication

业务运行11111***dependency*dependency1产品定义Product

Component

Spec

dependency11***11*Namespace11**过程思考(1)->概念模型建立对应的部署架构（容器与VM兼容）ComputeNodeComputeNodeComputeNodeMasterNodeStorageNodeStorageNodeStorageNodeStorage

Cluster…B1p2p1p3B2p5p4p6B2’p4’p5’p6’B3p8p7BNpypxpzServiceService_B1Service_B2Service_B3Service_BNStorageNode…ReplicationSControllerBControllerRControllerpControllerNetServiceIPHostIPprocessIPStorageIPNamespace过程思考(2)->设计原则隔离失败宽进严出PDCA（重在反馈）MVP过程思考(3)->数据说话0304产品生产时间生产过程数据…0102关键数据各技术框架的测试数据（开源基线）QPS=N/R…MTTR>MTBF不同规模的故障演练…与规模的关系与硬件条件的关系几个9…平台作为产线单项服务MTTR其他关键能力(1)->异构环境管理硬件设备NASSANDAS本地存储存储交换机防火墙路由器网络虚拟化层混合管理层计算管理存储管理网络管理kvm、xen计算管理存储管理网络管理EXSI计算存储网络容器x86服务器小型机服务器计算资源池存储资源池网络资源池池管理认证服务镜像服务配置基础服务资源监控故障处理策略与控制监控运维迁移备份分组映射容灾租户角色功能与接口权限管理统计趋势决策负载与容量申请审批帮助自助自动伸缩漂移管理优化调度计算存储网络…开发一区开发二区测试一区预发区生产区…ContainerContainerContainer关键能力(2)->容器资源的隔离与互通ContainerContainerContainerContainerContainerContainerOuter12341234同一Pod里的所有容器拥有同样的网络空间，可当本地（）访问Pod之间的网络采用内部IP的方式调用，每个Pod拥有自己的IPPod可暴露成service，每个service有自己的IP（虚IP），下层是Pod集群，可通过service进行集群调用通过宿主机的端口映射，解决外部访问内部的问题互通关键能力(2)->容器资源的隔离与互通隔离1234一级隔离：通过宿主机隔离，比如vlan划分不同的集群二级隔离：通过Namespace隔离，kernel4+以后，隔离性已经得到更多完善三级隔离：通过逻辑子网隔离，借助Flannel、OVS等完成四级隔离：通过Service和Pod进行隔离，默认通过iptables的策略进行关键能力(3)->伸缩与漂移监控调度伸缩漂移系统：获取CPU、内存等即时信息业务：配置流量、连接数等健康：获取Pod、Service等运行信息合理：获取机器负载、Pod特征等信息动态调整Replication数，并将信息更新到管理节点动态调整Pod所在的计算节点，并将信息更新到管理节点原则：Result

=

func1*weight1

+

func2*weight2

+…+funcn*weightn示例：检查符合的计算节点资源余量配置标签…检查最优的计算节点资源均衡资源最多…关键能力(3)->伸缩与漂移存储监控关键依赖非共享（ISCSI等块设备）共享（NFS、GlusterFS等网络文件系统）（有状态服务需要共享支撑）点：CPU、内存等系统数据，以及服务的状态数据面：整个业务区的资源、业务运行情况，如负载与容量线：端到端的数据，并在每个节点关联点的状态数据（时序库的使用、Metrics的设计）（全局号）关键要求：快、准、灵关键能力(4)->升级与回退CanaryRecreateRolling

UpdateRolling

Back…关键

原子化发布，每次操作都是一个原子化的操作，便于作为最小的单位粒度管理

标签设计，对于资源需要有唯一的组标识，比如滚动升级，是对同一组资源进行

状态设计，Desired、Current、Up-to-date、Available

版本规范，无论升级回退，都是需追溯到某一版本的，尽量不要做局部更新

路由能力，尤其是在灰度等多版本并存的场景下，对流量的管理是关键关键能力(4)->升级与回退示例：金丝雀+灰度负载均衡器容器资源池编译App=PortalRelease=1.1镜像App=PortalRelease=1.1Env=Prod,App=Portal发布容器Env=ProdApp=PortalRelease=1.0容器Env=Prod容器Env=ProdApp=PortalRelease=1.0容器Env=ProdApp=PortalRelease=1.0容器Env=ProdApp=PortalRelease=1.0App=PortalRelease=1.1容器Env=Canary容器Env=Pre容器Env=PreEnv=Pre,App=PortalApp=PortalRelease=1.0App=PortalRelease=1.1容器Env=ProdApp=PortalRelease=1.1容器Env=ProdApp=PortalRelease=1.1App=PortalRelease=1.1App=PortalRelease=1.1App=PortalRelease=1.1切忌把容器当VM用数据落在本地变更无版本管理关键能力(5)->熔断与降级Closed进：失败计数器归0过程：每次失败调用，计数器+1出：/Open进：启动时钟过程：持续禁止访问出：/Half-Open进：成功计数器归0过程：每次成功调动，计数器+1出：/成功调用次数达到了给定时间的阈值失败调用次数达到了给定时间的阈值达到超时时间调用失败熔断：与股市熔断概念一致，当调用下游服务出现问题时，需要自行进行智能处理降级：由于整体资源出现瓶颈时，为保证核心服务的可用性，将低等级服务暂停设计思路概念关键点上游服务服务A服务B服务C线程池A线程池B线程池C关键能力(6)->服务注册与发现注册中心A注册中心B服务端集群客户端集群registerregisterServicePodPodProviderConsumer1