这段时间一直在为了找工作学习，因为现在企业都要求会微服务，做为一个已经有5年开发经验的程序员，不会点微服务实在说不过去，所以为了找工作，还有加上自己的好奇，这段时间把为服务系统的学了一下。先看了网上的一期学习视频，看完后有了个感性的了解，知道了微服务springCloud是什么？解决什么样的问题？怎么使用？这些问题在脑海里基本有个模糊的答案，然后看了两本书《微服务设计》和《Spring Cloud微服务实战 》，吸收了一些内容，觉得有必要把学习到的总结一下。
关于什么是微服务？
“微服务是小而协同工作的自治服务”，作者这样定义。我谈谈我的理解，从字面上来讲“微服务”就是“小的服务”，"小"体现在服务在原来传统的单体应用上进行了拆分，大而化小，小而内聚，把原来在同一个应用的不同模块，拆分成了可以独立部署的服务，提高了独立性和降低了耦合性。“服务”这个词体现了服务治理，不是简单的各个模块拆开就成了微服务，拆分之后还需要有机的整合，能够很协调的一起工作，这样的才能算合格的微服务。相比传统单体应用而言，项目的个体是更小了，但是项目总体结构变庞大了，因此微服务有其利，有其弊，关于微服务的利弊后面谈谈。
微服务为什么会出现，解决了什么问题？
微服务是近五年内流行起来的概念，微服务的出现是伴随着我们的项目出现的问题给出的解决方案。传统的单体应用随着业务的发展、功能的升级、项目的迭代，代码可能变得越来越臃肿，越来越庞大，各模块间耦合度高不易扩展的问题，维护起来开发人员怨声载道等等，这时候要解决这些问题，需要把项目各个部分模块化，但是仅仅是项目内的模块化还是不能够解决根本问题，随着业务的调整变动还有可能会参和到一起，而且这种模块化各个功能单位还是在一个进程之内，一个功能引发的故障可能会殃及全池，整个系统瘫痪。所以解决这个问题需要更彻底的独立，各个模块独立一个进程、模块之间的交互以服务的形式接口调用，所以这个时候微服务应运而生。
微服务的优缺点
微服务给我们带来了“高内聚，低耦合”这些好处的同时也给带来了新的问题，下面说说我理解到的优缺点：
优点：
- 减少耦合：更为彻底的模块化、组件化开发，减少系统耦合，易扩展；
- 安全性：各个模块独立进程，避免相互影响；
- 技术异构：各个模块可以针对不同的模块的业务特点选择不同的技术架构，甚至不同的语言；
- 组织分工：有利于团队的分工，比如某个人或某几个人专门负责某个项目。
缺点：
- 运维难度：系统架构上更庞大，从开发、测试、部署、运维都提出了新的要求，比单体应用复杂；
- 故障概率：独立的项目增加同时也是增加了一个新的故障点，提高了故障概率，但是相对来说影响面减少了，这一点可以说两平了；
- 服务性能：相对于单体应用进程内的方法调用，微服务之间的http或rpc调用方式成本更高。
结合以上对于一个大的项目微服务的方式还是优胜于劣，架构的复杂必然会带来维护的难度。
微服务的实现
微服务的实现不仅仅是开发的层面，包括架构、开发、测试和运维都需要调整。
1、服务划分
第一步需要进行服务的划分，服务的划分是很关键的一步，决定了服务之间是否能很协调的工作，划分的不好将来有很多很蹩脚的操作。
划分追求的目标是“高内聚，低耦合”，识别出业务边界，相同的功能组织在一起，保证服务之间的独立性，减少依赖。
划分的步骤是自上而下，先粗后细，先整体后局部。
2、技术集成
微服务涉及的技术很多，RPC、HTTP、RESTful 、消息队列、zookeeper、dubbo、springCloud等等，这些技术都是围绕着这几个方面的技术实现：
- 服务间的通信：服务间可以采用HTTP或RPC通信，相对于RPC，HTTP更具有灵活性和技术兼容性，所以大部分的微服务都是采用HTTP通信；微服务的api更强调规范性，一般都采用RESTful规范。
- 服务的注册和发现：服务注册和发现是微服务核心的部分，把分散的服务在这个层面统一起来。服务端向注册中心注册服务，客户端从注册中心获取服务清单调用对应服务端。这部分可以用zookeeper或eureka实现。
- 服务的保护：服务间的调用相比进程内的方法调用更不稳定，所以需要提供一定的安全策略来应对这些风险，比如服务熔断、隔离和降级。
- 服务的负载均衡：一个服务可以部署多个服务实例，使用负载均衡分担压力。
- 服务路由和过滤：服务的调用如果需要有一个统一的入口进行服务的路由或过滤，这时候可以引入网关这个角色。
- 服务的监控：监控服务的健康状态，并发量。
- 服务的配置：项目被拆分成多个子项目后管理配置是一个难题，微服务需要更容易服务的配置，这时候配置中心这个角色出现了，使用配置中心可以统一管理服务的配置文件，配置文件可以放在一个git仓库，还可以区分不动的环境（开发、测试、生产）。
这些技术中dubbo和springCloud是一个微服务整体的框架，涵盖里微服务所需要的技术实现。dubbo是采用RPC调用，springCloud采用HTTP，相对来说springCloud更灵活、功能更全面丰富，是目前较dubbo更流行的框架。
3、单体应用的分解
从原来单体应用到微服务，改造是一个很庞大的工程，需要科学的规划，按一定步骤来，循序渐进。可以从项目内模块的分离-->数据库的分离-->项目的分离-->融合成微服务，这个过程实现。
- 1）项目内模块的分离：先把项目模块做好拆分，每个模块独立的目录，注意模块间的接缝部分，避免过耦合。
- 2）数据库的分离：数据库根据模块做好拆分，最好按模块独立一个数据库，公共的部分可以考虑一个公共的模块，将来独立的服务。数据库的分离也可以考虑分两个阶段，第一阶段实现同一个库，表按模块分离；第二阶段实现数据库分离。
- 3）项目的分离：在模块已经分离的基础上把模块拎出来作为单独一个项目。
- 4）融合成微服务：解决服务间的调用问题，引入微服务框架。