华为云微服务架构学习笔记

微服务引言

微服务出现的动机,现在业务变革太快了,要求技术架构需要跟上变化,

从单体架构到soa架构到微服务架构,灵活性,轻快做了进一步演进,从互联网公司到企业级的应用CRM系统,金融系统

不仅仅是应用的架构,自组织团队,完成分析开发测试部署运维,7~8个人;技术实践;流程与工具

Serverless(微服务),Martin Flower(发明人),独立部署,独立演进,允许技术多样性,模块化边界性

原来只需要运维一个应用,现在需要应用多个

原来单体调用(在进程内),现在要远程调用,慢,可靠性

单体应用用数据库的事务保持一致性,但是微服务有多个数据库,可以多实例连接一个数据库,用最合适的数据库技术,原来是关系型数据库,EJB强事务,但现在有些用redis和mongDB非关系型数据库,保持数据的一致性

微服务架构解决方案

华为云微服务产品,微服务引擎CSE微服务引擎

降级,访问剧增的时候把一些服务关闭,页面上也不会显示相关的内容

灰度发布:有两个版本,一个是1.0版本,一个而是2.0版本,2.0版本的筛选条件设置为成都,即在搜索别的城市,eg广州的时候

选择1.0版本,搜索成都的时候选择2.0版本.

微服务治理之负载均衡,分发到多个服务器,提供响应反应快的实例,提供最快的告诉

微服务治理之限流,超过限流请求量,防止故障蔓延

微服务治理之熔断,可能有级联故障,有因服务者不可用导致"调用服务者不可用"的问题,当窗口请求数超过20,或者失败率超过60%之后,熔断5000ms后再次恢复

微服务治理之容错,提供四种容错机制,出现异常以后的策略failover:失败后自动切换,在其他机器上进行测试;Failfast:失败后立即返回结果,不重试

Failback:失败后在同一个服务器上重试;custom:自定义;

CES开源版本ServiceComb

ServiceComb基于华为内部的CSE(Cloud Service Engine)框架开源而来，这个框架在华为内部已经存在了2年多，支撑了多个大型的商业项目。有相对传统的企业级项目，也有类似手机应用这样的互联网属性比较强的项目。并且在成为整个华为公司统一的微服务标准框架后，依然有越来越多的产品在逐渐使用它开发自己的微服务。

“不用SpringBoot的原因”，这个问题本身就有问题，因为ServiceComb并不阻碍你用SpringBoot，也不阻碍你用SpringCloud。如果你用这两个技术，可以把ServiceComb当做封装好了的几个starter，可以让你更方便地构建你的应用，就像楼主同学所说，在ServiceComb里面对Netflix OSS的一些组件做了很深度的集成和封装，不像SpringCloud这样一个大杂烩，在ServiceComb里面从头到尾进行了封装。你可以把它想象成是提供了类似Fegin的标记式开发方式，提供了SpringMVC的开发方式，提供了JAXRS的开发方式，然后对于你来说，这就够了，因为你用了这些开发方式开发了代码以后，LB、Hystrix已经被封装在后面了，你不用自己再去构建Command来用Hystrix。当然，如果你想自己扩展也可以。但是你也真的可以不用SpringBoot而只用ServiceComb。原因么，内部产品太多，各个团队水平和情况各不相同，有的就是不愿意用SpringBoot我们也没办法。动不动就说影响了他们几个亿的大买卖我们也很无奈啊。所以其实ServiceComb的第一个内部版本我们是依赖SpringBoot的，但是后面逐渐优化逐渐瘦身，开出来的版本已经不再强依赖SpringBoot了（注意，不依赖不表示不能一起用）。

对于Dubbo，微服务不是说好了“各个微服务用最适合的语言写不能绑定语言”吗？不是说好的“每个进程是一个微服务”吗？所以我们认为它是一个非常优秀的SOA时代的RPC框架，但是就微服务而言，它还有一些问题。

微服务全生命周期管理

微服务开发生命管理,放大优势,减小复杂度

微服务运维生命管理:devops,通过治理