开场白

现在有些公司还在用以前的单体架构，单体架构及系统流量很大的时候，并发量提不上来，很容易系统阻塞导致运转不起来，这个时候微服务就是为了解决这种痛点，微服务，及把单体服务拆分成多个微服务，采用了分治思想，不过拆分的微服务也是要有度才行，不能分得太细；要遵守面向业务、大道至简、分而治之的三个原则，同时考虑到公司的业务需求，投入产出，系统扩展等。

架构选型

选型一

1、nginx可以做路由转发，同时可以动静分离，缓存，反向代理、负载均衡
2、网关(zuul,gateway),网关可以负载均衡，认证鉴权，数据加密
3、微服务，就是各个子系统，订单服务，商品服务等
4、eruka是服务注册和服务发现，包括client,和server，各个微服务注册到上面，client通过拉取的服务列表进行查询服务，然后通过http访问服务。
5、缓存redis可以提高访问速度
6、定时任务可以对需要异步处理的逻辑，进行定时处理
7、消息队列，可以进行系统解耦，流量削峰，异步处理，日志处理，数据同步
8、文件系统，可以专门存储文件，比如fastDFS,hadoop,gfs
9、cdn，可以用来加快文件的访问速度
10、数据库(mysql),开源，系统成熟，可以用来存储有结构化的数据
11、云主机，用来部署服务的硬件服务器
这个架构并发不是很大，所有的业务请求，在同一服务，没有api层，并且容易出问题。

选型二

这个架构多了一个api聚合服务，所有的终端通过网关，然后访问聚合服务，聚合服务所有业务的api，放到了同一个微服务里面，这样做有利于api的代码管理及提高开发效率；缺点是并发不是很高，多人开发容易产生冲突。

选型三

这个架构，api聚合服务，改成了多个api微服务，这样做，可以提高并发性，但是缺点也是不利于前期开发，每个业务得有个api比较分散，代码不容易管理，部署稍微复杂。

总结

1、上面三种架构各有优缺点，其中很多微服务是公共的，比如订单服务，商品服务，这些对于那些不是从零开始搭建系统的项目，可以做成公用的，也就是公共基础服务。
2、对于那些从零搭建系统的项目，刚开始最好是每套系统是独立的，有利于项目的顺利进展，及需求的按时实现。
3、对于高并发的系统，可以采用架构三，同时可以采用各种集群，页面静态化，cdn，线程池，消息队列，缓存，提高并发量；限流，熔断，降级，切流量，版本回滚,超时与重试来保证高可用。
4、总之，架构就是利用最小的人力成本来构建和维护需求的实现。