【九月打卡】第一天  微服务架构的演进过程

第一模块：

课程名称：Spring Cloud / Alibaba 微服务架构实战

课程章节： 第二章 理解微服务架构，清楚微服务设计原则

主讲老师：张勤一

第二模块：

今天学习的内容包括：

什么是微服务，微服务优缺点，微服务设计原则,微服务架构的演进过程

第三模块：

微服务架构的演进过程

单体架构

1.1 初期单体架构

 单体架构设计非常简单  比如电商系统当中 把所以业务写成一个工程中 列如对应来说一个Java应用 包含鉴权 监控 订单 商品 物流 优惠 账号等服务实现 存储在MySQL 和Redis 当中

1.2 优点

       开发、部署、 上线非常简单

1.3 缺点

   1.代码耦合严重、牵一发而动全身,代码合并冲突很容易常见。

   2.维护困难，开发人员很难整体理解整个系统

   3.容错性差，因为整个系统是一个进程，如果系统报错，整个系统容易宕机    4.资源不能进行合理利用，一个系统中不同的功能被被调用的频率不同，如果是单体应用的话，需要将整个应用水平扩展，造成了资源的浪费。    5.不利于技术的扩展，传统的单体架构如果要更新某个技术，就需要重新开发整个系统    6.难以扩展，不能按需扩展，而要扩展整个系统。代码库比较复杂，进行修改维护容易影响到别的功能

2.垂直应用架构 （单体架构的升级改进）

2.1 垂直应用架构设计图

2.2 优点

     服务、部署独立、水平扩展容易

2.3 缺点

     搭建复杂，服务之间关系错综复杂，维护困难

SOA 架构（垂直应用架构的升级改进） 也叫面向服务架构

3.SOA 架构设计图

3.2 优点

   1.能够提高开发效率，可以将整个系统分为几个不同的子系统，不同团队负责不同的系统，从而提高开发效率。    2.解耦，降低了系统之间的耦合    3.易于扩展，业务逻辑改变时只需要修改单个服务，减少了对使用者的影响  

3.3 缺点

   抽取的粒度比较大。耦合度较高 开发周期比较长

4 .微服务架构 （业界最流行的软件开发架构）

4.1 微服务架构设计图

4.2 微服务优点

微服务是通过将系统根据功能划分为细粒度的服务，每一个服务都是一个独立的应用，根据这种思想创建的软件服务实体就是微服务。  

1.解耦，根据功能将系统分为不同的独立运行的服务，将原来的复杂的系统简单化，每个服务交付给不同的团 队去负责，提高了开发效率。开发人员可以只关注自己的业务功能  

2.容错性高，将错误隔离在单个服务内。

3.技术选型灵活，不同的服务可以根据自己的需求选择不同的技术。

4.易于扩展，可以按需扩展服务，避免资源的浪费  5.独立部署，每个服务独立部署，当其中一个服务有需求变更时，可以只编译部署单个应用，减少了对用户的影响

4.3 微服务缺点

1.开发人员需要面对分布式系统的复杂性。测试更加困难，需要保证服务之间的通信；需要团队之间的协调；当用例涉及到多个服务的时候，需要实现分布式事务管理。

              2.部署比较复杂

               3.增加内存开销，微服务系统用多个服务实例取代了传统垂直架构的单个服务实例。有多少服务实例，就会有多少在内存运行的开销。

5.微服务架构需要遵循的原则

5.1 微服务带来的收益

    1.合理、正确的将单体应用迁移到微服务

    2.单个的微服务，可以选择一门你擅长的语言去开发,扩展性强

    3.对于整个应用而言,代码不在耦合,不会出现大量的冲突

    4.微服务可以重用，应用发布时间可控性更强

    5.通过故障隔离，让错误在微服务中降级,不会影响到整个应用（或其他服务）

5.2 不遵循微服务架构原则会出现巨大的问题

       1.微服务之间的依赖错综复杂，难为维护

       2.开发过程 互相纠缠 开发  上线时间严重影响

建议的最佳实战

1.职责独立：每个微服务只做自己功能范围内的事,微服务之间的依赖链不要过长

        2.建立单个微服务依赖链路不要超过3个请求

        3.使用熔断器实现快速的故障容错和线程隔离  Hystrix Sentinel  

        4.通过网关代理微服务请求,网关是微服务架构对外暴露的唯一入口

5.确保微服务API 变更后能够向后兼容

课程收获

总结：

1.对于通用的功能逻辑，如果不经常变更，那么，做成 SDK，而不是提供一个服务

2.微服务通信链路如果『太长』，就需要考虑去重构、重新拆分微服务

3.学会微服务优缺点 微服务并不是拆的越细越好，而是合理就好。

4.今天学习课程共用了2个小时，重新学习一下微服务划分原则   大家一起加油 🏻