目录
一、单体架构的问题
微服务为什么会出现？在学习Springboot的时候知道Springboot极大的简化了我们的开发，我们可以快速的进行业务开发，Springboot单体应用在项目的开发初期能够满足我们需求，这种单体架构优点非常的明显：
容易测试：本地就可以起完整的系统，不需要外部依赖。
容易开发：我们只需引入依赖，选择框架便可快速开发。
易于部署：单体架构部署也较简单，直接打包即可。
易于水平伸缩：这里的收缩时指当我们需要多个服务器时也比较方便
在项目刚开始的时候我们可以快速的开发，一个长寿的项目，需求不断增加，原先的模块也再不断优化，这个时候单体架构的缺点开始显现：
代码膨胀，难以维护：代码越来越多，开发人员也就越来越多，一旦出现bug，定位、修复成本很高，而且人员太多，代码都放在一起，容易引起冲突，且由于业务集中在一起，业务复杂，很难全局把握，改一个bug可能会再多出两个bug。
构建、部署成本大：项目太大，构建和部署就会非常慢，效率低下。
上手困难：互联网企业人员更迭快，代码过于集中，导致业务非常复杂，新人想要上手变得非常困难。
技术创新困难：代码过于集中，我们很难使用到新技术，因为改动实在太大，容易出现问题。
可扩展性差：这里的可扩展性是指因为项目都必须部署在一台服务器中，那项目所要的资源会越来越大，这样我们只能扩展硬件（集群可以分散压力，但是单个应用所要的资源还是不能少的）。
二、微服务出现
微服务的出现就是为了解决这些问题，看看是如何解决的，微服务将系统拆分成一个个小服务（一般是按照模块进行拆分，比如用户服务、支付服务、订单服务、出入库服务等），那么即使业务量增加，我们也可以通过新增服务的形式来解决，这样代码就不会膨胀，构建、部署也不是问题。由于服务不在一个框架中，那么我们可以很方便的对某一个服务进行技术创新，对一个服务的进行技术升级改动不会太大，而当我们有新技术产生时，我们就可以也可以应用到新服务中。
微服务并没有明确的定义，下面是一种比较通用的理解：
使用一套小服务来开发单个应用的方式，每个服务运行在独立的进程里，一般采用轻量级的通讯机制互联，并且它们可以通过自动化方式部署。
通过定义我们可以知道微服务的特征：
微服务是由一系列的小服务共同组成的。
每个微服务都有自己独立的进程。
每个服务都是独立的业务开发，单一原则
每个服务都能独立的部署（一般部署在容器中）。
微服务之间通过轻量级通信机制进行通信
分布式的管理。
三、微服务架构图
讲到这里，对微服务的概念应该有了一定的了解，下面画的一个比较简单的微服务架构图
图中可以看出每个微服务都有自己独立的数据库，每个服务都会暴露自己的REST API 给外部调用，服务之间会存在互相调用关系，而每个服务都有可能被客户端直接调用，另外我们看到还有一个API Gateway,这是统一个服务接口，它通常可以有以下作用：
1. 提供统一服务入口，让微服务对前台透明
2. 聚合后台的服务，节省流量，提升性能
3. 提供安全，过滤，流控等API管理功能
四、优缺点
凡是都有两面性，一个技术也不可能只有优点而没有缺点，微服务的优点很多，微服务的优点其实就是单体架构的缺点的反面，因为微服务本身就是来解决单体架构问题的
独立性：微服务从构建、部署，扩容、缩容、甚至数据库都是独立的，服务只要管理好自己就可以，这样就极大的降低了系统的复杂性。服务完全独立独立之后，从构建到部署，到后期的扩容缩容都会变得简单，基本就解决单体架构上碰到的很多问题。
敏捷性：敏捷性是针对开发人员来讲的，服务拆分之后，可以独立专一开发，开发人员可以通过API快速的了解本服务的业务，互相之间并不影响。
技术栈灵活：微服务可以完全独立的拥有技术栈，只需要保证提供的服务API不变，内部使用何种技术栈很灵活。
高效的团队：微服务的团队会比较小，那沟通就会变得更加高效。
没有最好的架构，只有最适合的架构，既然有这么多优点，那缺点肯定也有不少
服务的拆分：服务如何拆分其实是非常重要且复杂的，服务拆分的太大或太小都不合适，这需要我们有非常丰富的经验，而这个在单体中是不存在的。
数据一致性：单体架构中只有一个数据库，我们可以通过事务解决多表之间数据的一致性，而在微服务中，每个服务中都有自己独立的数据库，要保证服务之间的数据一致性也是一个大的挑战。
服务间通信成本：服务间互相通信也需要时间成本。
测试复杂性提高：服务之间存在依赖，那么测试时就必须启动这些依赖，这就增加了复杂度。
运维部署复杂性提高：微服务应用由大量服务组成，每个服务会起多个实例，要进行配置，部署，扩展和监控。此外，还需要实现服务发现机制
五、技术点
要实现微服务，我们需要解决以下几个技术点：
客户端访问服务：这个上面架构图中已经给出，使用API Gateway。
服务通信：服务与服务之间的通信有两种方式，同步与异步：
同步通信中又分为两种：Http与RPC，http访问很好理解，相信一般的系统也会调用外部的一些服务，这些基本都是使用http,因为http可以跨语言，跨客户端，相对使用较广，如http Client ,而RPC也有自己的优点，首先是效率更高，更安全可控，特别是内部服务互相调用时，用统一的RPC框架，服务的侵入性更低，调用服务甚至就像调用自己的服务一样简单,如dubbo（注：dubbo只能使用java语言）。
异步通信是通过消息队列来实现，异步通信的好处是可以降低服务之间的耦合，有削峰的好处，而且使用消息队列可以方便的实现数据的最终一致性。
服务治理：为了服务的高可用，微服务一般都有多个拷贝，做负载均衡，而这个时候就必须知道服务的状态，一个服务随时有可能下线，下线之后后续有可能重新启动，这些都需要我们一个服务治理功能，也即是服务的注册与发现。
产品服务启动了三个，他们都会去注册中心进行注册，注册成功后，会通过心跳包告诉注册中心是否在线或者下线，而订单服务要去调用产品服务，会先去注册中心进行查询，查询出相应的地址然后再去调用产品服务。
服务崩溃处理：在运行期间会出现服务崩溃的情况，比如网络原因，阻塞原因，这个时候服务并不是下线，还是能够被找到，我们必须妥善要进行处理，否则可能会导致整个系统的崩溃，处理的方式有：
重试机制
熔断机制
降级机制
限流机制
六、解决方案
以上都是微服务的一些概念，既然有天上飞的概念，就有落地的实现，现在主流的微服务架构有两套解决方案：Dubbo+Zookeeper与SpringCloud。
我司现在两种方案都在用，总体来说两种方案都可以很方便的进行微服务开发，其中的区别在于SpringCloud组件多，功能完备，全家桶式，基本微服务中会遇到的问题都有相应的解决方案，在通信方面SpringCloud使用的是http。
而Dubbo+Zookeeper使用的是RPC，组件较少，功能非完备（但是我们可以自己去找相应的解决方案），并且现在交由Apache进行孵化，后面应该会实现功能的完备。
就个人来说，认为Dubbo+Zookeeper的侵入性更少，且调用过程更简单，更加类似服务之间的调用，两种方案后续就会进行学习。
写在最后：
码字不易看到最后了，那就点个关注呗，只收藏不点关注的都是在耍流氓！
关注并私信我“架构”，免费送一些Java架构资料，先到先得！
