微服务123

前言

       读了基本关于微服务的书，看了些博客，也实战了些demo,但还是不能系统的对微服务进行理解，只记得只言片语，思维都是混乱的，所以想通过这个帖子来系统的学习总结下微服务的相关知识，只是为了加深印象而已。

一、定义

       微服务就是一些协同工作的小而自治的服务，其核心是化繁为简、化整为零，把应用分解为小的服务模块进行独立开发，微服务的这一特点使其便于部署到容器，对整个开发、测试、运维都发生了革命性影响，有力地支持了devops开发，提高效率，便于维护升级和故障处理，带来了一系列优势。

       一个微服务一般完成某个特定的功能，比如下单管理、客户管理等等。每一个微服务都是微型六角形应用，都有自己的业务逻辑和适配器。一些微服务还会发布API给其它微服务和应用客户端使用。其它微服务完成一个WebUI，运行时，每一个实例可能是一个云VM或者是Docker容器。

二、特点

       微服务的特点在于根据业务提炼不同的服务，系统经过拆分，根据不同的功能划分出基础服务和核心服务。各子系统调用多个核心服务完成功能，核心服务调用多个基础服务。核心服务之间和基础服务之间不能互相调用。一般服务模块只能访问自己的数据库，对其他数据库的数据，通过调用其服务提供的接口完成。

三、优势

•复杂度可控：在将应用分解的同时，规避了原本复杂度无止境的积累。每一个微服务专注于单一功能，并通过定义良好的接口清晰表述服务边界。由于体积小、复杂度低，每个微服务可由一个小规模开发团队完全掌控，易于保持高可维护性和开发效率。

•独立部署：由于微服务具备独立的运行进程，所以每个微服务也可以独立部署。当某个微服务发生变更时无需编译、部署整个应用。由微服务组成的应用相当于具备一系列可并行的发布流程，使得发布更加高效，同时降低对生产环境所造成的风险，最终缩短应用交付周期。

•技术选型灵活：微服务架构下，技术选型是去中心化的。每个团队可以根据自身服务的需求和行业发展的现状，自由选择最适合的技术栈。由于每个微服务相对简单，当需要对技术栈进行升级时所面临的风险较低，甚至完全重构一个微服务也是可行的。

•容错：当某一组建发生故障时，在单一进程的传统架构下，故障很有可能在进程内扩散，形成应用全局性的不可用。在微服务架构下，故障会被隔离在单个服务中。若设计良好，其他服务可通过重试、平稳退化等机制实现应用层面的容错。

•扩展：单块架构应用也可以实现横向扩展，就是将整个应用完整的复制到不同的节点。当应用的不同组件在扩展需求上存在差异时，微服务架构便体现出其灵活性，因为每个服务可以根据实际需求独立进行扩展。

四、数据库设计

      据库设计是架构设计的关键部分，项目需要进行统一的架构分析和设计，数据库也需要统一设计，根据需求和微服务的划分，给不同的服务设计合适的数据库，从整体上系统规划，才能科学合理地搞好数据处理，保证系统的数据一致性、正确性和有效使用。

1.微服务架构的数据库是各自独立的，各个服务有自己的数据库，便于单独开发和维护。在架构设计的时候，需要根据业务和系统的特点，合理划分数据库，减少冗余，保证数据的一致性和正确性。

2.数据量大的数据库，需要分库分表，进行垂直和水平拆分，并进行读写分离，提高性能。

3.对冷热数据需要分开，热数据存在微服务使用的数据库，冷数据存在hbase或mongodb。

4.数据库需要开启log和定期备份，便于在出故障后恢复，确保数据的安全。

5.大量使用redis缓存，消除数据库瓶颈，提高系统反应速度。

6.各微服务具有自己独立的数据库，负责数据的CRUD，别的服务不能直接操作其数据库，必须通过本服务完成对数据库的操作。

五、Docker容器部署微服务

        Docker是运行微服务的最佳解决方案，容器+微服务是一个革命。Docker实际上是一个应用容器的引擎，可以让开发者非常方便地把自己的应用以及这个应用所需要的所有依赖都打进容器镜像当中，且具有可移植性，能够部署到任何服务器上。

      微服务采用Kubernetes管理Docker，多个应用系统通过Docker形成集群，Kubernetes可以简单有效地管理各个集群。

 

六、微服务与devops

      微服务和docker，非常适合devops开发，一个image把开发、测试、部署、运维全流程打通，一键部署，有效地提升效率和质量。