微服务的架构适合你吗？微服务为什么而来？
前言
最近拾起了基本英文的讲微服务的书，一方面是学习英文，一方面也是想原汁原味的了解一下外国人口中的微服务是怎么样的。因此这篇文章是想聊聊微服务，聊聊我眼中的微服务，和实践微服务中的一些经历。也是这么多年实践微服务的一些思考。前端
你们认为的微服务
先来聊聊我在面试中遇到的微服务。java
在公司作通道评委的一个好处就是能够看到不一样部门同事形形色色的工做内容，这是一个很是好的机会，能了解公司其它部门业务详细状况的机会，在这个评审工做中，你能够详细的问这些同事的工做，甚至让他给你看看代码。评委一般会从几个问题点来问问题：nginx
你项目的系统架构是什么样的程序员
你的项目有什么技术难点的golang
你的项目和公司内同类项目，或者业界项目有哪些优点web
这种状况下面试者准备的东西也不少，因而不少时候就会出现直接套用当前比较火的技术名词，百度，google 看看，只要有点意思就会：哦，我原来作的和这个技术很像啊，原来咱们在搞这么高深的技术。微服务就是其中一个。我在屡次的评审工做就遇到一个作业务活动的同窗指着本身ppt上的一个网站架构说这就是微服务。我把一个大服务，分红了几个服务独立发布，再在前端统一整合起来，采用了微服务架构。这说的好像也没问题。。。面试
在面试的时候我也常常会问面试者这样的问题：后端
你的系统数据流图画一下，你的系统模块架构图画一下设计模式
你认为你项目的技术难点在哪里安全
和同类项目比，你的优点在哪里
这里也会听到各类各样的回答，有的说，我修改了 nginx，让它作服务网关；或者说我本身用 golang 开发了一个本身的服务网关，让整个服务采用了微服务架构；我把这个后台模块拆分红了 5 个小模块，采用了微服务架构。。。好像说的也是没什么问题。
到底一个qps流量只有几百的小网站把后台拆成多个模块叫不叫微服务架构呢？或者写了一个网关亦或架设了一个 nginx 来代理后端多个服务的流量叫不叫微服务？或者把后台模块拆成了几个小模块叫不叫微服务呢？
微服务是由于什么而出现的
一种技术不可能没有缘由的就出现了，也不可能没有缘由的就火起来。因此我认为咱们首先要思考的是微服务是为何而来的呢？为何早期的软件设计中没有这个概念呢？我在上学的时候学习的软件设计方法都是 UML，面向对象的软件开发，学习设计模式。架构都是 MVC，Slave-Master， C/S。。。前几年在学习 golang 的时候我还用 golang 把 23 中设计模式参考 java 的实现都从新实现了一遍。
从个人理解来尝试解答这个问题：微服务架构为什么而来？
我认为主要有如下 3 个主要缘由：
软件系统变得愈来愈复杂。
软件需求量大增，须要让更多的开发人员低门槛的进入开发。
大型软件的交付周期加速，软件平台化交付的需求增长。
软件系统变得愈来愈复杂
首先，目前在企业级的应用中，软件系统是在愈来愈复杂，动不动千万级，亿级访问量的软件服务愈来愈多，尤为是 4G 移动时代的到来，让以往的软件开发模式有了较大的挑战，以我以前在作大搜索的例子来讲，整个搜索引擎由100多个大大小小的模块组成，有些部署个几台机器，有些部署上千台机器，其中的调用关系更是错综复杂。
若是你说搜索引擎这个例子是太大了，在非 4G 时代已经就这么复杂了。那么咱们来讲说其它的软件服务，微信，QQ 也很大很复杂，咱们也不论。就说说游戏的活动系统，好比说一个游戏的领奖活动。以下图： 
这也是简单画了其中依赖的服务模块，而不是所有的服务，目前所有设计的服务模块加起来要有 30 个左右。你们不要惊讶，这其实已经不多了。并且这只是一个常见的游戏网页活动的涉及到的模块。主要由于仍是如今企业级的软件不像以往的单机软件了。今天看到一个帖子说经典游戏《魂斗罗》的整个编译后的程序只有120kB，并且里面包含了那么多声音和关卡，想一想如今随便一个手机软件都是几十兆起步呀。
如今企业软件的开发主要考虑的大并发，多地域的云上服务。就连微软的 office 也在走这个路子。并且软件服务模式也变了，以往大多数是以购买 key 的方式，而如今是云上持续的内容付费服务。经过在云山不断的发新内容，让用户不断的消费。客户端依然已经只是成为了一个渠道。因此企业软件的发展模式就走向了轻客户端重服务端。这也要求了服务端的服务能力和服务内容可以快速更新变化，不少内容是天天变，实时变。软件的功能升级节奏也是要求更短更快。
因此须要一种新的开发模式来支持这样的软件开发。
软件需求量大增，须要让更多的开发人员低门槛的进入开发
如今整个社会已经被软件吞噬，这一点都不夸张。若是说十几年前使用软件和接触计算机仍是个稀罕事，那么如今若是你不会使用软件才会是一个稀罕事。咱们的生活的各个角落都是软件，进小区大门，去饭馆点菜吃饭，支付，打车，坐公交。。。。离不开，真离不开。
由此而来的也是大量的软件人员的持续投入，大量培训后的程序员在走向软件开发行业。若是说早先会写代码的黑客们都是顶级大牛，那么如今不少的被培训后的程序员只能是蓝领劳动力提供者。而事实上也是如此，大牛们在不断的减低软件开发的门槛，从开发语言，开发的IDE，到开发的操做系统。都在一步步走向有更好的开发体验，更低的开发门槛。这使得软件开发能够更为普及，你只须要知道你要作什么便可，不用像以往的大牛们对底层系统，甚至是底层硬件都熟悉的不得了。而如今，呵呵。。。。固然如今高级程序员也是有的。
因此这种需求驱动之下，须要新的软件开发模式来可让更多的程序员能够接入开发，像上面的图中，或许前端的 web 开发的人只须要知道 web 开发的知识就能够了，不须要知道推荐，实时计算和发奖支付的逻辑。分工在逐步的细化。
大型软件的交付周期，软件平台化交付的需求增长
这个是不言而喻的，企业级的大型软件为了使用用户和社会的快速变化的需求，就须要有一种能力：快速的内容和功能更新。这也是如今微服务架构中最引以自豪的就是这一点，单个功能的快速迭代。
微服务架构 VS 单体架构
微服务架构和单体架构是软件实现的不一样方式，固然单体架构出现的要比微服务架构早。可是这并非说微服务架构就必定比单体架构好，架构没有好坏之分。好坏之分在于架构是否是适应业务的需求。
因此下面咱们先来看看微服务架构和单体架构各自的优点，其实在必定程度上微服务架构的优点都是针对单体架构提出来的。
微服务架构的优点
先来看看若是你采用微服务架构，会获得哪些好处。
微服务架构可让开发者使用多种语言开发，多个开发者同时参与一个项目的时候，他们可使用微服务架构而采用各自很是熟悉的开发语言进行快速高效的开发，让开发进度更快。
可让不一样的团队独立的去管理服务，基本上每一个服务能够有本身独立的开发和发布节奏，每一个开发团队负责本身的这个模块的开发和发布就能够了。在必定程度上减小了依赖。
能够针对同一个服务的不一样版本同时进行线上发布。其实这个在单体服务里面也能够作到，可是在这个不一样团队去作的时候，他能够根据网关路由，针对不一样的服务能够用不一样的版本。就是同一个服务也能够有不一样的版本，同时进行服务。
可让你对独立的服务和模块进行独立的扩容，就是好比说登陆组件，那么容量不够的时候只要对登陆模块进行单独扩容就能够了，而不用对整个服务进行总体扩容。
能够独立的作安全管控，好比说这个服务只容许那些服务来访问，在独立的模块上设置独立的安全策略，让某些服务来访问就好了，而不是对全部的这个内部服务开通管理。
单体架构的优点
那接下来咱们再来看一下单体服务的优点。
首先就是它的安装和部署，相对来讲没有微服务那么复杂，要关心多个模块之间的依赖关系。
统一配置，服务整合在一块儿，那么不少相同的配置就只须要配置一份了，对服务的管控能够更统一。
升级维护简单，只要升级这一个服务啊，并不须要对服务的各个组件都要逐个升级。
扩容更方便，扩容的时候只须要扩容这一个模块就好了，不须要细分到扩容那个模块。
调试更方便，全部的日志，可能就打在一台机器上，调试的时候只要看一个地方的日志就能够了。微服务的调测：看关系链，看日志是个很大的问题。
启动时间整体上来讲会更短，拆分的服务会有互相依赖，因此一套微服务架构的系统启动速度是个问题，要等待几乎全部的模块都准备好了才能对外服务。
服务调用时间会更短，这个就不用说了，微服务间是以远程调用为主的，而单体架构是函数级调用，这个个想一想就知道了。
代码管理维护会相对简单。
你的哪些项目不适合微服务架构，如何选择架构
疯狂的石头，疯狂的微服务，在每一个人都为微服而疯狂的时候，咱们都要冷静下来去想想，思考一下微服务到底适不适合我，适不适合我这种场景，从我上面的这个分析来看，微服务，很是适合于大团队，大项目，对于你一我的就能够搞定的项目来讲，最好仍是单体架构，好比说你我的负责整个服务的一个后台服务，那后台服务里面可能有 4，5 个功能，那你这 4，5 个功能其实没有必要拆成为微服务去作。由于服务的拆分必然会增长服务维护成本，因此你们必定要在收益和付出的成本之间进行平衡。这里也不是必定说不要拆，合理的拆分是有必要的，可是能合并的必定要尽可能合并。千万不要为了微服务而微服务。
而对于多个团队共同来负责开发的项目，这个时候，就颇有必要引入微服务，每一个团队负责不一样的模块。以此来构建总体的服务，再经过服务网关对外服务。
这种状况下的拆分是跟组织架构有关系的，必定是不一样团队负责不一样的模块，而每一个团队只须要对本身的服务模块进行负责，进行功能开发的，更新发布，他有本身的开发节奏。
总结
在微服务的开发过程中，你们容易出现这种一叶障目的状况，你们只看到微服务的好，可是没有看到微服务带来的这个成本。这个时间在 isito 的架构变迁中有很好的验证，在早期的版本里，它是微服务架构的的，可是在最新的 1.5 版本里面，改为了单体架构。这是为何呢？由于 istio 里面全部的组件都是在一个仓库里面，并且这些组件，都是由同一个 isito 团队的成员维护的，并无造成多个团队。另外做为一个服务咱们要讲求开发体验，若是你的部署维护成本过高，这就意味着你的使用成本和门槛很高。而采用这个单体架构以后，至少比以前大大简化了服务的部署和维护成本，使用体验和开发体验上就有很大的提高。
最后，咱们的目标是采用合理的架构，解决你的问题，而不是为了引入微服务，另外你们在采用微服务的同时必定要看看我上面的微服务的优势，更要看看单体架构的优势。