微服务相关笔记一

       随着系统越来越庞大，参与人员越来越多，这时候人员的交流成本，发布成本，变动成本越来越高。这时候我们开始选择更改组织架构，项目架构来改变这种系统越来越庞大所带来的副作用。

    康威定律，一个项目的架构等同于其组织架构。

    说白一点微服务其实就是一种模块化形式，提供标准接口，和当年硬件标准化一样，其内部结构不一致，但是其提供的接口是一致的。即使不同厂家生产的我们也可以即插即用，而且可以将我们的优势发挥出来，只关注我们的业务模块即可，不必关注其他服务或者硬件的好坏，只要关注自己领域的业务，并且提供标准接口即可

    在说明一件事的好处之前，我们要预计其所带来的坏处。微服务带来的坏处有哪些：

      1.最终一致性

      2.测试复杂性

      3.运维复杂性

     4.硬件成本

  我觉的最重要的一点就是最终一致性(事务)，目前业内没有一个大家都认可的全局事务处理框架，阿里目前出的fescar，seata还是项目建设初期，还有待完善。

  测试复杂，一个测试用例需要多个服务应用进行配合，不是之前测一个流程即可。

 运维复杂，需要多个服务进行配合才能把系统启动成功

  硬件问题,目前微服务之间都是通过网络互相调用，有通过http,有通过rpc来进行互相调用，不管使用何种方式这时候就需要我们的网络性能很强大，如果微服务之间的网络如果达不到万兆带宽的时候，就开始微服务，使用网关将会是非常痛苦的一件事情