微服务学习归纳

写在最前

        照例唠几句，从《代码整洁之道》就认识了Martin，也拜读他的博客，从他提起微服务就一直挺有兴趣，没能抽出时间来实战写一个练手项目，今年开年后终于各种杂事都告一段落，开始慢慢啃书啃博文就商城题材写一个项目。项目丢github写了一半，又要生活所迫找工作，在这里先对之前学习的内容做一下归纳总结。

---

概念

       微服务架构有别于传统架构将所有功能放在一个解决方案中发布，它将功能分解成一系列松耦合的服务，这些服务通过某种协议进行互相协作完成原单体架构下的业务功能，提供了更灵活的布署模式，更容易扩展，降低开发运维复杂度。所以微服务的核心理念是分治。

       微服务架构将应用功能分而治之，使得架构上有如下优点：1.松耦合：降低系统内部重构变动对用户的影响。2.抽象：改变某个服务的数据只依赖该服务的接口，每个服务对数据有绝对控制权，方便对数据进行控制。3.独立和更高的可用性：各个服务可以分开打包发布，独立上下线，不影响其他服务。

       当然微服务也有部分缺点，比如说：1.分布式事务问题：用户请求业务涉及多个微服务保障一致性，比如说下单涉及到订单、商品是否可用、库存是否充足等。2.全能对象难以拆解：订单就是一个涉及多方的对象。3.系统更复杂：加大了学习难度和服务编排治理，依赖较大的服务一旦挂了会造成系统雪崩。

微服务拆分原则

        我把拆分规则作为一个重点板块来归纳，因为这是微服务架构中最重要的一点，一旦没能遵守规则拆分，最后只会成为套了一份微服务壳子的单体系统集合。一般地，我们遵循两条原则（出自《敏捷软件开发：原则、模式与实践》）：1.单一职责原则：原文中指一个类应该只有一个职责，不应该有更多改变类形态的原因。推理到微服务中就是微服务应该有且只有一个职责，以免造成业务之间的高耦合使业务改变时埋下不稳定因素。2.共同封闭原则：共同封闭原文是指一个变化如果对一个封闭包产生变化，则将对该包所有的类产生影响，而不影响其他包。归纳到微服务就是，我们应该将业务上联系紧密、会因为同一个原因改变的服务放在一个微服务。总结下来就是将业务关联较高的服务放在一起，除此之外全部拆分。比如说在某些应用可以根据业务将用户服务放在一起，但是应用中如果有用户服务关联不紧密的情况也可以拆分用户服务、拆分为登录注册服务等。

微服务基本构成

      微服务架构一般会有以下几种非功能性微服务：

       1.服务治理微服务，用以服务发现、服务注册、服务治理等。

       2.服务统一入口：用以统一转发到各个服务的统一入口

       3.权限管理服务：用以管理微服务对外接口的权限验证

       4.性能监控服务：用以监控各个微服务的健康度

       除了以上还有一些非功能性微服务，这里就不一一列举了。

微服务和SOA对比

SOA是面向服务的架构，通常是松耦合的，它将服务进行拆分，通过ESB进行交互和消息调用，一般地，还是整个项目级别拆分，大家用的还是相同的开发语言、数据库。

微服务则是在SOA基础上升华，每个服务都是独立并存的，它可以是不同开发语言、不同数据库只需要遵守同一个交互协议就可以进行互相调用。

---

写在最后

        对微服务的概念理解还是比较浅薄，可能从实践项目上更能学到东西吧，我会继续写那个github的练手项目的。学习微服务的过程中，我参考Martin Fawler的博文、《Spring Cloud 微服务架构开发实战》等资料，都是非常好的学习资料。