我也想写篇微服务的文章，以及微服务的优缺点

什么是微服务

首先，微服务不是一个名字，而是一个架构的概念，就像Restful不只仅是描述api的格式，而更多的是描述基于Restful API的架构是同样的。微服务架构（MSA）是对原来的大型系统而言的，经过横向或者纵向、业务或者架构切分，将一个大型的系统分散成不少微型小系统。当系统复杂到必定程度时，几十号人共同维护一个系统的效率很低，并且出问题的风险也很高。这时候就须要对系统进行切分，很早以前提出的SOA系统，和微服务的架构理念不谋而合。你们如今使用的基于RPC框架（dubbo、thrift等）的架构也能够视为一种微服务。微服务到如今为止尚未确切的边界和定义，貌似计算机上不少概念都定义不出来边界。可是，我理解微服务之间的通讯是http通讯，传统rpc调用方式并非严格的微服务，由于他不能自理，须要依赖，好比可能必须某个rpc服务Producer存在的状况下，rpc服务的Consumer才能启动起来。因此，下文中的讨论，我都以微服务之间以http通讯为前提。

微服务有什么好处

1. 解耦：对于咱们底层程序员而言，看得见的好处就是解耦。我要实现一个功能，可能并不须要很深刻的了解别人的代码，由于程序员嘛，可能都以为别人的代码是个渣渣([啼笑皆非])。我能够新做一个微服务，这个服务为其余功能提供服务，又不依赖于原来已有的功能，至于业务逻辑，能够一边上手一边熟悉
2. 内聚，能够独立部署：意思就是我维护的这个微服务，能够独立部署，对其余服务不会是强依赖，不会存在由于其余服务不存在而形成我本身的服务不能启动或者不可用的问题
3. 分布式：微服务架构下不存在一个特别大的系统包含不少中心功能，这样也能提升容错性，一个服务的瘫痪并不会让整个系统瘫痪
4. 权限验证：微服务是高度内聚的服务，我本身的这个服务，我能够定制任意合理规则，而这个规则又只适用于我本身的服务。相比于dubbo RPC调用，http微服务调用的权限验证能够更直接更严格更定制化，而rpc调用时的权限验证，我我的始终以为不能作的很优雅
5. 数据分开治理，自带分库属性：原来的大系统使用一个数据库，当数据不少流量很大时，就会涉及到分库分表。而微服务下，每一个服务是否使用数据库，数据库是和其余服务公用仍是自建，都有很大灵活性，即我以为微服务自带分库分表属性
6. 系统不会被长期限制在某个技术栈上，在微服务的架构下，整个系统不会受限于java或者nodejs 或者go，而是你们协同不冲突，所有http协议，json格式
7. 各个模块的单元测试容易自动化
8. 等

微服务面临的挑战

1. 通讯，http请求速度慢，一般一个操做可能会涉及到多个微服务的相互调用，若是为了完成一个操做而屡次从服务端调用不一样的微服务，http请求的耗时可能会成为瓶颈，如图1所示。
   
2. 客户端与服务端的通讯须要一个 API GateWay：一般状况下，客户端和微服务们不在一块儿，而各个微服务会集中部署在一个机房，那微服务之间的互相调用是很快速的，可是客户端和微服务之间的调用会是耗时的。并且，用户的一个动做不能在客户端进行屡次连续调用，这样一来速度慢，二来会有泄漏系统架构的风险。正常状况下，在客户端和微服务架构之间会有一个API GateWay，如图1变成图2所示，GateWay最重要的做用是为客户端提供后台服务的聚合，提供一个统一的服务出口，解除他们之间的耦合，为了解决API Gateway单点故障点或者性能瓶颈，一般Gateway也是一个集群，并且客户端的访问控制、帐号管理、登陆管理等切面一般会在这里处理
   
3. 微服务不少时，整个链路可能很长，调用失败的风险高，并且e2e自动化测试会成为一个问题
4. 服务注册和服务发现，我司有本身的服务管理系统。我推荐etcd。Google开源的Kubernetes(k8s)貌似也是使用的这个。
5. 分布式事务，这个是微服务系统的大难点，可能须要根据本身系统的状况和业务需求进行定制了，我推荐补偿性分布式事务和基于消息的分布式事务。(下次有时间介绍一下经常使用的集中分布式事务要怎么作)

下篇会讲一下，咱们用什么框架或者用什么工具，能快速搭建一个微服务系统。