微服务架构与实战笔记

第1章  单块架构及其面临的挑战

               一  补一下三层架构

表示层	聚焦数据显示和用户交互
业务逻辑层	聚焦业务逻辑处理
数据访问层	聚焦数据的存储与访问

                          1.  一层架构和二层架构

                               一层架构

                                     将所有的页面逻辑、业务逻辑以及数据库访问逻辑放在一起，这是我们通常提到的一层架构，我们早期的

                              ASP、JSP以及PHP，这是受了面向过程的影响。如下图所示

                           

                               二层架构

                                       业务逻辑与表示层逻辑交织在一起，数据访问逻辑独立出来。这是因为发展出了高级语言如Java、.net，，

                               这些语言提供了方便的数据访问机制，如JDBC。

                         

                          2.  三层架构

                               三层架构的优势

                                    （1）解决应用程序中代码间调用复杂、代码职责不清的问题。

                                    （2）三层架构的出现从某种程度上解决了企业内部如何有效根据技能调配人员，提高生产效率的问题。

                                             在大环境下，有效地分层能使不同职责的人员各司其职，更聚焦于个人专业技能的发展和培养。

               二  为什么要使用微服务的架构

                            要解释这个问题，应该从单块架构的优缺点着手

优点	缺点	缺点说明
易于开发	维护成本增加	庞大复杂。系统越来越复杂，代码量越来 越多，定位问题困难，缺陷修复困难
易于测试	持续交互周期长	构建部署时间长,开发团队耦合度高各功能 合并难
易于部署	新人培养周期长	代码复杂，需要熟悉的业务增多
易于水平伸缩	技术选型成本高	技术改革涉及修改过多
	可扩展性差	垂直扩展贵，水平扩展性差
	构建全功能团队难

第2章 微服务架构综述

             一  什么是微服务架构

                         1. 什么是微服务架构                 

                                    微服务架构是一种架构模式，它提倡将单一的应用程序划分为一组小的服务，服务之间互相调用、互相配

                             合，为用户提供最终价值。每个服务运营在其独立的进程中，服务与服务之间采用轻量级的通信机制互相沟通

                           （通常是基于HTTP的RESTful API），每个服务都围绕具体的业务进行构建，并且能被独立部署到生产环境、

                             类生产环境等。另外应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下

                             文，选择合适的语言、工具对其进行构建。

                         2. 微服务的“微”

                                    这个“微”并不是一个真正可衡量、看得见、摸得着的“微”，这个“微”所表示的是一种设计思想和指导方针。

                         3.  微服务架构的特点

                            （1）单一职责

                                             对于每个服务而言，我们希望它处理的业务逻辑能够单一，在服务架构层面遵循单一职责原则。也就

                                     是说，微服务架构中的每个服务，都是具有业务逻辑的，符合高内聚、低耦合原则以及单一职责原则的单

                                     元，不同的服务通过“管道”的方式灵活组合，从而构建出庞大的系统。

                                     扩展，自己一直没有研究过的高内聚低耦合

                                     本文摘自博客：https://blog.youkuaiyun.com/qq_39521554/article/details/79489180

                                     --  高内聚

                                                高内聚的简单解释：系统中存在A、B两个模块进行交互，如果修改A模块而不影响B模块的工作，

                                                                                那么认为A模块有足够的内聚。

                                                       软件含义上的内聚其实是从化学中的分子的内聚演变过来的，化学中的分子间的作用力,作用力

                                                强则表现为内聚程度高。在软件中内聚程度的高低，标识着软件设计的好坏。我们在进行架构设计

                                                时的内聚高低是指，设计某个模块或者关注点时，模块或关注点内部的一系列相关功能的相关程度

                                                的高低。

                                                       例如，下单模块都会有如下的信息，订单的信息，产品的信息及谁下的单(买家信息)。这是基本

                                                的，那么我们设计的时候就要把相关的功能内聚到一起。当然这是从大功能(下单管理)上来说，当然

                                                这些模块还可以再细化分成产品、订单、会员等子模块。

 

                                                        再例如，我们设计数据库的查询辅助类的方法有增加、删除、修改、查询，经过分析发现应该

                                                把这些功能都是操作数据库的，应该放在一个类中（内聚），使该类只负责数据库的相关操作。这

                                                样就提升了可维护性和可重用性。

                                                什么是低内聚？

                                                       模块的功能不单一，模块的职责不明确，比较松散，更有甚者是完成不相关的功能。

                                                低内聚意味着什么？

                                                       低内聚的模块则意味着模块直接的依赖程度高，那么一旦修改了该模块依赖的对象则无法使用该

                                                模块，必须也进行相应的修改才可以继续使用。

                                                设计高内聚的模块思路：

                                               

                                      --  低耦合

                                          低耦合的定义：低耦合是用来度量模块与模块直接的依赖关系

                                                 耦合当然也可以这样简单的理解，我想懂电脑的应该都知道，CPU与主板之间的关系，CPU如果是特

                                          殊的CPU必须使用特殊的主板来支持，那么如果说这个CPU不唯一依赖唯一主板，那么就认为这个CPU与

                                          主板的关系是低耦合的关系。下面我们来举例说明低耦合的设计与高耦合的设计：

                                           

                                           

                                                 这是一个简单的低耦合的设计，电器与插座之间是低耦合的关系，就算我替换了不同的插座，电器依

                                          然可以正常的工作。因此简单的描述如下，就是A模块与B模块存在依赖关系，那么当B发生改变时，A模

                                          块仍然可以正常工作，那么就认为A与B是低耦合的。

                                                 在例如，对应一般的音响来说，笔记本是通用的，音响和笔记本直接的关系是低耦合的，但是笔记本

                                          和耳机却是高耦合的，只有专配的耳机才能和笔记本互联使用，而不是通用的，所以说笔记本和专配耳机

                                          存在着较强的依赖关系。

                                                 如何构建低耦合的设计：

                                              

                            （2）轻量级通信

                                     所谓轻量级通信机制，通常指语言无关、平台无关的交互方式。如REST。

                            （3）独立性

                                     独立性是指在应用的交付的过程中，开发、测试部署的独立。

                            （4）进程隔离

                         4. 微服务不仅表现出一种架构模型，同样也表现出一种组织模型。

                                    这种新型的组织模型意味着开发人员和运维的角发生了变化，开发者将承担起服务整个生命周期的责任，包括

                             部署和监控，而运维也越来越多地表现出一种顾问式的角色，尽早考虑服务如何部署。因此，如何在微服务的实施

                             中，按需调整组织架构，构建全功能的团队，是一个不小的挑战。

                         5.  微服务诞生的背景

                            （1）互联网行业的快速发展

                            （2）敏捷、精益的方法论深入人心

                            （3）单块系统架构面临的挑战

                            （4）容器虚拟化技术

                         6.  微服务与SOA

                              实际上微服务可以看作是SOA的一个子集

                             

                               微服务与SQA的区别

SOA	微服务
企业级，自顶向下开展实施	团队级，自底向上开展实施
服务山多个子系统组成，粒度大	一个系统被拆分成多个服务，粒度细
企业服务总线，集中式的服务架构	无集中式总线，松散的服务架构
集成方式复杂（ESB/WS/SOAP）	集成方式简单（HTTP/REST/JSON）
单块架构系统，相互依赖，部署复杂	服务能独立部署

             二  微服务的本质特征

                    1. 服务作为组件

                    2. 围绕业务组织团队

                               在单块应用架构时代，为了节省成本、提高人员效率，企业或者组织一般都会根据技能划分团队。譬如，用户体

                        验设计师，一般都被划分到设计团队：懂服务器端的开发人员，一般都被归类为后端业务逻辑开发团队：精通数据库

                        技能的开发者，一般会在DBA团队中

                               当团队被按照这个策略或者维度划分后，即便是某些简单的需求变更，都有可能出现跨组织、跨团队的协作，沟

                        通协作成本较高。正如康威定律所述，一个组织的设计成果，其结构往往对应于这个组织中的沟通和组织结构。

                               微服务架构的团队组织方式不同于传统的团队组织方式，它提倡以业务为核心，按业务能力来组织团队，团队中

                        的成员具有多样性的技能。

               3.关注产品而非项目

                       基于产品模式构建团队（19e后期）而非基于传统的项目模式构建团队（京北方、19e前期）

                    4. 技术多样性

                    5. 业务数据独立

                    6. 基础设施自动化

                    5.演进式架构

             三  微服务实施过程中应该考虑的问题

                      1. 分布式系统的复杂度

                          --  性能

                          --  可靠性

                          --  异步

                                    分布式中为了增加吞吐量，很多时候采用了异步通信的机制，但异步通信在享受非阻塞的同时也大大增加了

                              功能实现的复杂度，并且出现缺陷时，定位问题、调试问题的难度也更大

                          --  数据一致性

                          --  工具

                               IDE没有为分布式系统提供足够的支持，因此分布式架构的开发、调试存在着较大的负责性

                      2. 运维成本

                      3. 部署自动化

                      4. DevOps与组织架构

                                 DevOps就是开发（Development）和运维（Operations）这两个领域的合并。有时候，DevOps还包括产品管

                          理、QA、*winces* 甚至销售等领域。

                                微服务不仅表现出一种架构模型，同样也表现出一种组织模型。这种新型的组织模型意味着开发人员和运维的

                          角发生了变化，开发者将承担起服务整个生命周期的责任，包括部署和监控，而运维也越来越多地表现出一种顾问

                          式的角色，尽早考虑服务如何部署。因此，如何在微服务的实施中，按需调整组织架构，构建全功能的团队，是一

                          个不小的挑战。

                      5. 服务间依赖管理

                                 对于传统的单块架构而言，通常使用集成测试验证系统是否和其外部的依赖之间正常协作。而对于微服务架构

                         而言，由于系统被拆分成多个可独立部署的、分布式的业务单元，因此，服务之间的交互主要通过接口完成。在服

                         务数量逐渐增多的情况下，如何有效地保证服务之间能有效按照接口的约定正常工作，成为微服务实施过程中，测

                         试面临的主要挑战。

    

                                      

转载于:https://www.cnblogs.com/jialanshun/p/10637454.html