如何选应用架构

最近微服务架构非常流行，10个人的小公司做个项目也要求把微服务架构做为硬性条件，网站日访问量不到1000的web应用也要求用微服务架构，那么到底使用微服务架构好不好，我来通俗 的讲一下。要弄清楚这个问题，需要理解下面几个流行语。

集群

通俗解释一下集群：为了建设一栋房子，需要砌砖，一个人砌砖太慢，需要10个人砖瓦工人同事去砌，这样就大大提高了效率，我们说这10个人就组成了一个集群。集群是所有人都是干同 一件事，大家一起干，每个人相互之间不依赖。放到我们的软件生产环境，集群就是通过堆积服务器硬件来做同一个工作来提高效率。

分布式

分布式，顾名思义，就是有个分工的概念。还是用砌砖的例子来说，我们砌砖，需要先把搬运砖头，放到墙边，需要水泥砂浆，然后才能开始砌砖的工作。如果和水泥砂浆，搬砖，砌墙都 给同一个人做，即使是10个人，可能效率也不高，这个时候分布式就上场了。我们可以安排2个人专门和水泥砂浆，2个人搬砖运到墙下，6个人只管砌砖。这种情况下，虽然人员没有增多， 但是效率肯定会提高。那可以这么理解，集群不一定是分布式，但分布式肯定是集群，它需要多个服务器来协同工作。那这个时候，还会有一个问题，如果水泥砂浆没有了，那砌砖工人需 要通知和水泥砂浆暂停，赶紧把弄好的水泥砂浆运到墙边。现实中可以用嘴喊，可以手机打电话，服务器这个时候怎么通知，这就涉及到rpc（remote process communication），这个我们 简单提一下，下次可以单独深入讨论。

微服务

微服务是一种架构，原理和分布式很像，它的拆分粒度很细，细到每个人仅做一件不可分解的事情，而这些细微的事情不一定每个都放在不同服务器上，一个服务器上可以放很多微服务如A服务，B服务，C服务，另外一台服务器放B服务，C服务，D服务。值得注意的是，所有服务都需要通知一个叫注册中心的地方，可以理解这个为工程项目经理，他来统一协调管理。

总结

如果你的业务很简单，访问量也很少，那所有应用放一台服务器也可以流畅的运行，这个时候连集群都不需要用。如果你的访问量很少，但是业务很复杂，打个比方，以电商下单为例，下 单的过程，需要提交订单，支付，同事需要核查仓库是否有库存，然后再把地址发给第三方物流下单，如果这些事情放一起做，需要30秒。用户需要等待30秒才能看见自己是否购买成功了 ，这样体验非常不好，即使你的平台一天只成交100单， 访问量很小，用户体验还是不好，这个时候你可以用分布式来解决这个问题，把支付，查库存，通知第三方物流等拆分成5个或者更 多的工作。这样，用户体验大大提高，几秒就可以完成一次购物。如果你的访问量很大，每个流程步骤很复杂，那这个时候，你可以将步骤分布式，再多分配几个服务器集群，这个时候用 微服务架构就更合适了。根据之前运营app的经验，日访问量几百万，每个交互都是2秒以内的应用，只要带宽足够，将web和数据库分离加上一个redis缓存，2台主流服务器就足够了。