多研究些架构，少谈些框架（1） -- 论微服务架构的核心概念

微服务架构和SOA区别

微服务如今辣么火，业界流行的对比的却都是所谓的Monolithic单体应用，而大量的系统在十几年前都是已是分布式系统了，那么微服务做为新的理念和原来的分布式系统，或者说SOA（面向服务架构）是什么区别呢？
咱们先看相同点：

• 须要Registry，实现动态的服务注册发现机制；
• 须要考虑分布式下面的事务一致性，CAP原则下，两段式提交不能保证性能，事务补偿机制须要考虑；
• 同步调用仍是异步消息传递，如何保证消息可靠性？SOA由ESB来集成全部的消息；
• 都须要统一的Gateway来汇聚、编排接口，实现统一认证机制，对外提供APP使用的RESTful接口；
• 一样的要关注如何再分布式下定位系统问题，如何作日志跟踪，就像咱们电信领域作了十几年的信令跟踪的功能；

那么差异在哪？

• 是持续集成、持续部署？对于CI、CD（持续集成、持续部署），这自己和敏捷、DevOps是交织在一块儿的，我认为这更倾向于软件工程的领域而不是微服务技术自己；
• 使用不一样的通信协议是否是区别？微服务的标杆通信协议是RESTful，而传统的SOA通常是SOAP，不过目前来讲采用轻量级的RPC框架Dubbo、Thrift、gRPC很是多，在Spring Cloud中也有Feign框架将标准RESTful转为代码的API这种仿RPC的行为，这些通信协议不该该是区分微服务架构和SOA的核心差异；
• 是流行的基于容器框架仍是虚拟机为主？Docker和虚拟机仍是物理机都是架构实现的一种方式，不是核心区别；

微服务架构的精髓在切分

• 服务的切分上有比较大的区别，SOA本来是以一种“集成”技术出现的，不少技术方案是将原有企业内部服务封装为一个独立进程，这样新的业务开发就可重用这些服务，这些服务极可能是相似供应链、CRM这样的很是大的颗粒；而微服务这个“微”，就说明了他在切分上有讲究，不妥协。无数的案例证实，若是你的切分是错误的，那么你得不到微服务承诺的“低耦合、升级不影响、可靠性高”之类的优点，而会比使用Monolithic有更多的麻烦。
• 不拆分存储的微服务是伪服务：在实践中，咱们经常见到一种架构，后端存储是所有和在一个数据库中，仅仅把前端的业务逻辑拆分到不一样的服务进程中，本质上和一个Monolithic同样，只是把模块之间的进程内调用改成进程间调用，这种切分不可取，违反了分布式第一原则，模块耦合没有解决，性能却受到了影响。

分布式设计第一原则 -- “不要分布你的对象”

• 微服务的“Micro”这个词并非越小越好，而是相对SOA那种粗粒度的服务，咱们须要更小更合适的粒度，这种Micro不是无限制的小。

若是咱们将两路（同步）通讯与小/微服务结合使用，并根据好比“1个类=1个服务”的原则，那么咱们实际上回到了使用Corba、J2EE和分布式对象的20世纪90年代。遗憾的是，新生代的开发人员没有使用分布式对象的经验，所以也就没有认识到这个主意多么糟糕，他们正试图重复历史，只是此次使用了新技术，好比用HTTP取代了RMI或IIOP。

微服务和Domain Driven Design

一个简单的图书管理系统确定无需微服务架构。既然采用了微服务架构，那么面对的问题空间必然是比较宏大，好比整个电商、CRM。

如何拆解服务呢？
使用什么样的方法拆解服务？业界流行1个类=1个服务、1个方法=1个服务、2 Pizza团队、2周能重写完成等方法，可是这些都缺少实施基础。咱们必须从一些软件设计方法中寻找，面向对象和设计模式适用的问题空间是一个模块，而函数式编程的理念更多的是在代码层面的微观上起做用。
Eric Evans 的《领域驱动设计》这本书对微服务架构有很大借鉴意义，这本书提出了一个能将一个大问题空间拆解分为领域和实体之间的关系和行为的技术。目前来讲，这是一个最合理的解决拆分问题的方案，透过限界上下文（Bounded Context，下文简称为BC）这个概念，咱们能将实现细节封装起来，让BC都可以实现SRP（单一职责）原则。而每一个微服务正是BC在实际世界的物理映射，符合BC思路的微服务互相独立松耦合。

微服务架构是一件好事，逼着你们关注设计软件的合理性，若是原来在Monolithic中领域分析、面向对象设计作很差，换微服务会把这个问题成倍的放大

以电商中的订单和商品两个领域举例，按照DDD拆解，他们应该是两个独立的限界上下文，可是订单中确定是包含商品的，若是贸然拆为两个BC，查询、调用关系就耦合在一块儿了，甚至有了麻烦的分布式事务的问题，这个关联如何拆解？BC理论认为在不一样的BC中，即便是一个术语，他的关注点也不同，在商品BC中，关注的是属性、规格、详情等等（实际上商品BC这个领域有价格、库存、促销等等，把他做为单独一个BC也是不合理的，这里为了简化例子，你们先认为商品BC就是商品基础信息）， 而在订单BC中更关注商品的库存、价格。因此在实际编码设计中，订单服务每每将关注的商品名称、价格等等属性冗余在订单中，这个设计解脱了和商品BC的强关联，两个BC能够独立提供服务，独立数据存储

小结
微服务架构首先要关注的不是RPC/ServiceDiscovery/Circuit Breaker这些概念，也不是Eureka/Docker/SpringCloud/Zipkin这些技术框架，而是服务的边界、职责划分，划分错误就会陷入大量的服务间的相互调用和分布式事务中，这种状况微服务带来的不是便利而是麻烦。
DDD给咱们带来了合理的划分手段，可是DDD的概念众多，晦涩难以理解，如何抓住重点，合理的运用到微服务架构中呢？
我认为以下的几个架构思想是重中之重

• 充血模型
• 事件驱动​下面两篇将为你们详细介绍这两个设计思路