Spring Cloud微服务——微服务

一、前言：

       本博客中所有的概念，小编都尽可能转换成了自己的理解，精简了概念！尽可能精简的来表达！

二、正文

    1、什么是微服务架构？

            一种系统架构上的设计风格！主旨：将一个系统拆分成可通信的多个独立部署运行升级扩展的微服务！

       2、微服务与单体系统？

        1）微服务与单体系统的区别、优点

                    单体初期方便开发和使用，但随系统逐渐增大，耦合性太强，维护成本大，难以控制，一挂全挂
                    微服务独立，不会互相影响，容错性强，易维护，敏捷开发，自动化部署！

        2）将单体系统变为微服务

                    ——————本质：将代码依赖变成了服务间的通信依赖

                    a. 实施微服务的问题：
                        i. 运维新挑战：进程数大大增加
                        ii. 接口一致性：拆分服务但业务依赖不会消除，服务间需要进行调用，所以需要更完善的接口和版本管理
                        iii. 分布式复杂性：服务独立部署并运行，只能通过通信来协作，分布式的问题都将存在，比如：网络延迟，分布式事物，异步消息等。

        3）微服务架构九大特性、

                    a. 服务组件化：服务独立可独立更换升级
                    b. 按业务组织团队：每个微服务都是针对特定业务的全栈实现，也就是说每个服务都要有一套完整的小团队，从而达到能全栈实现的目的
                    c. 做“产品”的态度：每个团队要对每个可独立部署运行的微服务的整个生命周期负责，所以都应该有做产品的态度
                    d. 智能端点与哑管道：不太理解（在单体应用中，主要通过函数调用交互协作，而在微服务中，因为服务不在一个进程，所以服务间通信会有不同，可以查下微服务架构中服务调用方式）
                    e. 去中心化治理：在实施微服务架构时，各个服务可以针对不同的业务特点选择不同的技术平台
                    f. 去中心化管理数据：可以将数据拆分到新的同平台的数据库实例中，也可以存储到不同平台的数据库实例中
                    g. 基础设置自动化：在实施微服务架构时，数据库，应用程序个头虽然小了，但数量也成倍增长。这会造成运维关注的内容，操作性任务成本增长，如果不妥然解决，必将成为运维人员的噩梦，所以基础设置自动化就是解决这个问题的。。解决办法：从一开始就构建“持续交付平台”如何构建持续交付平台：自动化测试和自动化部署缺一不可
                    h. 容错设计：微服务架构中，每个服务运行在独立进程，所以存在部分服务挂，其他正常运行的情况，而不存在一挂全挂的情况。为了更快速检测出故障并恢复服务，我们希望在每个服务中实现监控和日志记录。
演进式设计：初期以单体系统方式来设计实施， 随着系统发展，业务需要，架构师会将一些内容进行微服务处理，逐渐将单体系统中多变模块查分出来，而稳定不太变化的模块就形成一个核心微服务。