忘川彼岸|我只是下了个订单，鬼知道我在微服务里经历了什么？( 三 ) 【51CTO.com原创稿件】面试的时候

微服务的利和弊
既然选择了微服务，就得知道微服务的利和弊，特别是弊，引入了微服务，就等于引入了一套复杂的体系，一套复杂的体系带来的各种挑战必须事先了解清楚。
利
①强模块化边界
我们知道做软件架构，软件设计，模块化是非常重要的一点，一开始我们写程序做软件，我们采用类的方式来做模块化，后面开始采用组件或类库的方式做模块化，可以做到工程上的重用和分享给其他团队来使用。
微服务在组件的层次上面又高了一层，以服务的方式来做模块化，每个团队独立开始和维护自己的服务，有明显的一个边界。
开发完一个服务，其他团队可以直接调用这个服务，不需要像组件通过 Jar 或源码的方式去进行分享，所以微服务的边界是比较清晰的。
②可独立部署
③技术多样性
弊(或者说挑战)
①分布式复杂性
在原来单块应用就是一个应用，一个对单块应用的架构比较熟悉的人可以对整个单块应用有一个很好的把控。
但是到了分布式系统，微服务化了以后可能涉及到的服务有好几十个，一些大公司可能涉及到的服务上百个，服务与服务之间是通过相互沟通来实现业务。
那么这个时候整个系统就变成非常复杂，一般的开发人员或一个团队都无法理解整个系统是如何工作的，这个就是分布式带来的复杂性。
②最终一致性
微服务的数据是分散式治理的，每个团队都有自己的数据源和数据拷贝，比方说团队 A 有订单数据， B 团队也有订单数据，团队 A 修改了订单数据是否应该同步给团队 B 的数据呢?
这里就涉及到数据一致性问题，如果没有很好的解决一致性问题，就可能造成数据的不一致，这个在业务上是不可以接受的。
③运维复杂性
以往的运维需要管理的是机器+单块的应用，分布式系统和单块应用不一样的是，分布式系统需要很多的服务，服务与服务之间相互协同。
那么对分布式系统的资源，容量规划，监控，对整个系统的可靠性稳定性都非常具备挑战的。
只有在清楚了解微服务带来的挑战，明知道山有虎偏向虎山行，才能够真正的胜任挑战，最重要的是，要清楚明了里面有什么坑，怎么避免踩坑。
完美，已经了解微服务带来的好处和挑战，接下来就可以开始开发了。 ^?_?^
等等，微服务还没有做逻辑分层。
微服务怎么做逻辑分层
目前我们的微服务里面有几个服务，分别是订单，商品，用户。
如果客户端向查看 “我的订单” 这么一个接口;如果客户端假定是 PC 端，就需要请求三次接口，分别对接订单，商品，用户三个服务，分别拿完三次调用数据，再将三次调用数据进行整合输出展示。
要知道 PC 调用后端服务是走外网，这无疑大大增加了网络的开销，而且让 PC 端变成更为复杂。
假定在中间加多一个层为聚合服务层，即对网络开销进行减少，因为微服务内部是通过内网进行数据传输，也让 PC 端的业务变得比较简单。
图中的 “PC 聚合服务” 也是一个微服务，只不过它是属于聚合服务中间层，我们将为微服务进行逻辑划分，分为 2 个层：
①微服务基础服务层