首先，微服务不是一个名字，而是一个架构的概念，就像Restful不仅仅是描述api的格式，而更多的是描述基于Restful API的架构是一样的。微服务架构（MSA）是对原来的大型系统而言的，通过横向或者纵向、业务或者架构切分，将一个大型的系统分散成很多微型小系统。当系统复杂到一定程度时，几十号人共同维护一个系统的效率很低，而且出问题的风险也很高。
这时候就需要对系统进行切分，很早之前提出的SOA系统，和微服务的架构理念不谋而合。大家现在使用的基于RPC框架（dubbo、thrift等）的架构也可以视为一种微服务。微服务到现在为止还没有确切的边界和定义，貌似计算机上很多概念都定义不出来边界。但是，我理解微服务之间的通信是http通信，传统rpc调用方式并不是严格的微服务，因为他不能自理，需要依赖，比如可能必须某个rpc服务Producer存在的情况下，rpc服务的Consumer才能启动起来。所以，下文中的讨论，我都以微服务之间以http通信为前提。
微服务有什么好处
解耦：对于我们底层程序员而言，看得见的好处就是解耦。我要实现一个功能，可能并不需要很深入的了解别人的代码，因为程序员嘛，可能都觉得别人的代码是个渣渣([哭笑不得])。我可以新作一个微服务，这个服务为其他功能提供服务，又不依赖于原来已有的功能，至于业务逻辑，可以一边上手一边熟悉 内聚，可以独立部署：意思就是我维护的这个微服务，可以独立部署，对其他服务不会是强依赖，不会存在因为其他服务不存在而造成我自己的服务不能启动或者不可用的问题。分布式：微服务架构下不存在一个特别大的系统包含很多中心功能，这样也能提高容错性，一个服务的瘫痪并不会让整个系统瘫痪 权限验证：微服务是高度内聚的服务，我自己的这个服务，我可以定制任意合理规则，而这个规则又只适用于我自己的服务。相比于dubbo RPC调用，http微服务调用的权限验证可以更直接更严格更定制化，而rpc调用时的权限验证，我个人始终觉得不能做的很优雅 数据分开治理，自带分库属性：原来的大系统使用一个数据库，当数据很多流量很大时，就会涉及到分库分表。
而微服务下，每个服务是否使用数据库，数据库是和其他服务公用还是自建，都有很大灵活性，即我觉得微服务自带分库分表属性 系统不会被长期限制在某个技术栈上，在微服务的架构下，整个系统不会受限于java或者nodejs 或者go，而是大家协同不冲突，全部http协议，json格式 各个模块的单元测试容易自动化 等
微服务面临的挑战
通信，http请求速度慢，通常一个操作可能会涉及到多个微服务的相互调用，如果为了完成一个操作而多次从服务端调用不同的微服务，http请求的耗时可能会成为瓶颈，如图1所示。
客户端与服务端的通信需要一个 API GateWay：通常情况下，客户端和微服务们不在一起，而各个微服务会集中部署在一个机房，那微服务之间的互相调用是很快速的，但是客户端和微服务之间的调用会是耗时的。而且，用户的一个动作不能在客户端进行多次连续调用，这样一来速度慢，二来会有泄漏系统架构的风险。正常情况下，在客户端和微服务架构之间会有一个API GateWay。如图1变成图2所示，GateWay最重要的作用是为客户端提供后台服务的聚合，提供一个统一的服务出口，解除他们之间的耦合，为了解决API Gateway单点故障点或者性能瓶颈，通常Gateway也是一个集群，而且客户端的访问控制、账号管理、登录管理等切面通常会在这里处理
微服务很多时，整个链路可能很长，调用失败的风险高，而且e2e自动化测试会成为一个问题 服务注册和服务发现，我司有自己的服务管理系统。我推荐etcd。Google开源的Kubernetes(k8s)貌似也是使用的这个。 分布式事务，这个是微服务系统的大难点，可能需要根据自己系统的情况和业务需求进行定制了，我推荐补偿性分布式事务和基于消息的分布式事务。(下次有时间介绍一下常用的集中分布式事务要怎么做) 首先，微服务不是一个名字，而是一个架构的概念，就像Restful不仅仅是描述api的格式，而更多的是描述基于Restful API的架构是一样的。微服务架构（MSA）是对原来的大型系统而言的，通过横向或者纵向、业务或者架构切分，将一个大型的系统分散成很多微型小系统。当系统复杂到一定程度时，几十号人共同维护一个系统的效率很低，而且出问题的风险也很高。
这时候就需要对系统进行切分，很早之前提出的SOA系统，和微服务的架构理念不谋而合。大家现在使用的基于RPC框架（dubbo、thrift等）的架构也可以视为一种微服务。微服务到现在为止还没有确切的边界和定义，貌似计算机上很多概念都定义不出来边界。但是，我理解微服务之间的通信是http通信，传统rpc调用方式并不是严格的微服务，因为他不能自理，需要依赖，比如可能必须某个rpc服务Producer存在的情况下，rpc服务的Consumer才能启动起来。所以，下文中的讨论，我都以微服务之间以http通信为前提。
微服务有什么好处
解耦：对于我们底层程序员而言，看得见的好处就是解耦。我要实现一个功能，可能并不需要很深入的了解别人的代码，因为程序员嘛，可能都觉得别人的代码是个渣渣([哭笑不得])。我可以新作一个微服务，这个服务为其他功能提供服务，又不依赖于原来已有的功能，至于业务逻辑，可以一边上手一边熟悉 内聚，可以独立部署：意思就是我维护的这个微服务，可以独立部署，对其他服务不会是强依赖，不会存在因为其他服务不存在而造成我自己的服务不能启动或者不可用的问题。分布式：微服务架构下不存在一个特别大的系统包含很多中心功能，这样也能提高容错性，一个服务的瘫痪并不会让整个系统瘫痪 权限验证：微服务是高度内聚的服务，我自己的这个服务，我可以定制任意合理规则，而这个规则又只适用于我自己的服务。相比于dubbo RPC调用，http微服务调用的权限验证可以更直接更严格更定制化，而rpc调用时的权限验证，我个人始终觉得不能做的很优雅 数据分开治理，自带分库属性：原来的大系统使用一个数据库，当数据很多流量很大时，就会涉及到分库分表。
而微服务下，每个服务是否使用数据库，数据库是和其他服务公用还是自建，都有很大灵活性，即我觉得微服务自带分库分表属性 系统不会被长期限制在某个技术栈上，在微服务的架构下，整个系统不会受限于java或者nodejs 或者go，而是大家协同不冲突，全部http协议，json格式 各个模块的单元测试容易自动化 等
微服务面临的挑战
通信，http请求速度慢，通常一个操作可能会涉及到多个微服务的相互调用，如果为了完成一个操作而多次从服务端调用不同的微服务，http请求的耗时可能会成为瓶颈，如图1所示。客户端与服务端的通信需要一个 API GateWay：通常情况下，客户端和微服务们不在一起，而各个微服务会集中部署在一个机房，那微服务之间的互相调用是很快速的，但是客户端和微服务之间的调用会是耗时的。而且，用户的一个动作不能在客户端进行多次连续调用，这样一来速度慢，二来会有泄漏系统架构的风险。正常情况下，在客户端和微服务架构之间会有一个API GateWay。如图1变成图2所示，GateWay最重要的作用是为客户端提供后台服务的聚合，提供一个统一的服务出口，解除他们之间的耦合，为了解决API Gateway单点故障点或者性能瓶颈，通常Gateway也是一个集群，而且客户端的访问控制、账号管理、登录管理等切面通常会在这里处理
微服务很多时，整个链路可能很长，调用失败的风险高，而且e2e自动化测试会成为一个问题 服务注册和服务发现，我司有自己的服务管理系统。我推荐etcd。Google开源的Kubernetes(k8s)貌似也是使用的这个。 分布式事务，这个是微服务系统的大难点，可能需要根据自己系统的情况和业务需求进行定制了，我推荐补偿性分布式事务和基于消息的分布式事务。(下次有时间介绍一下常用的集中分布式事务要怎么做)