开始
互联网开发到了现在这个阶段，大家都在谈微服务。微服务火了这些年，不管是在公司开发（啥？公司没用？怎么可能？！现在不用点微服务公司那产品怎么提高档次？），还是出去面试，你要不谈点微服务相关的技术，都不好意思说自己是搞Java开发的。
自动微服务出现，身边好多团队都在鼓捣这个微服务，我觉得这是大势所趋吧，随着互联网开发到现在，很多软件产品已经开始微服务，甚至出现的新技术都是随着微服务这个方向去的。
就是微服务重点就是这个“微”字了，什么样的项目和产品需要微服务？其实这个没有定论，它没有标准答案，如果有人问你这个问题，你只能回答一个建议：
- 假如用户只有几千人不到1万人，单体应用是最好的选择
- 微服务会增加运维和研发成本，建议统筹考虑项目预算
- 如果有个上百万的用户量，那么微服务是一个比较好的选择了
微服务架构的通信机制
客户端与服务器之间的通信
在单块应用架构下，客户端应用程序（Web或者App）通过向服务端发送HTTP请求；但是，在微服务架构下，原来的单块服务器被一组微服务替代，这种情况下客户端如何发起请求呢？客户端可以向micro service发起RESTful HTTP请求，但是会有这种情况发生：客户端为了完成一个业务逻辑，需要发起多个HTTP请求，从而造成系统的吞吐率下降，再加上网络的延迟高，会严重影响客户端的用户体验。为了解决这个问题，一般会在服务器集群前面再加一个角色：API gateway，由它负责与客户度对接，并将客户端的请求转化成对内部服务的一系列调用。这样做还有个好处是，服务升级不会影响到客户端，只需要修改API gateway即可。
内部之间的通信
内部服务之间的通信方式有两种：基于HTTP协议的同步机制（REST或者RPC）；基于消息队列的异步消息处理机制。
微服务的优点与缺点
优点：
- 每个服务足够内聚，足够小，代码容易理解、开发效率提高
- 服务之间可以独立部署，微服务架构让持续部署成为可能
- 每个服务可以各自进行负载均衡扩展和数据库扩展，而且，每个服务可以根据自己的需要部署到合适的硬件服务器上
- 容易扩大开发团队，可以针对每个服务（service）组件开发团队
- 提高容错性（fault isolation），一个服务的内存泄露并不会让整个系统瘫痪
- 系统不会被长期限制在某个技术栈上 缺点：
- 开发人员要处理分布式系统的复杂性
- 微服务架构可能带来过多的操作
- 需要DevOps技巧
- 分布式系统可能复杂难以管理
- 当服务数量增加，管理复杂性增加
写到最后
因此业务规模的量，您的项目还是产品成本和收益之间的博弈决定我们是否做微服务改造？这个问题是必然的。
当我们决定开始做微服务的时候，要面临哪些技术问题？
springcloud核心组件有哪些，具体应用场景？
领域划分有没有具体方法？
