微服务架构介绍
1
f微服务是个说的挺长时间的概念，也是比较成熟的技术体系。像Spri
gCloud，甚至提供了微服务所需要的全套框架，包括注册中心Eureka、配置中心Co
fig、断路器Hytrix、API网关Zuul等组件。微服务体系庞杂，每个组件都能独自成章。微服务与更早就起来的SOA是什么关系个人觉得如果从概念上来说，微服务和SOA都是一回事，强调把整个系统，按照多个服务的方式去组合及通信，而不是揉合在一起，但它们的内涵有很大的区别。SOA诞生在早期企业级的应用，其业务复杂、技术体系多样，SOA强调的是各个服务之间，尤其是异构系统、遗留系统之间，建立起一套统一的协议和通信SOAP，以及寻址服务UDDI，它的侧重点在集成和兼容；与SOA同期的另一种概念ESB企业总线，强调通过一根总线服务，把所有服务串联起来，由ESB总线来屏蔽各种不同业务系统自身业务语言协议的特殊性，各服务以一种统一的方式，与总线相连，从而降低接入成本。这两种概念，我感觉在国内没有太发展起来。一是国内的软件起步相对较晚，系统的整体复杂度多厂商、多语言技术栈、历史遗留系统的问题，还不算突出。而对于公司内部的产品系，又没有必要使用SOA、UDDI来做复杂的集成。随着互联网的兴起和用户量的迅速爆发，企业自身的产品的微服务化的需求，快速发展起来，而与此同时SOA这种以XML为基础的SOAP协议、以寻址为主要作用的UDDI，不能使用互联网产品的发展SOAP的XML协议内容太多，造成性能明显下降；HTTP协议的效率不如RPC；UDDI只有寻址，缺少服务治理等功能。在此种大背景下，以服务切分服务注册服务治理限流降级RPC监控等为主要内涵的微服务，就快速发展起来的。国内的阿里巴巴走在前列，以Dubbo为代表在国内互联网企业中得到广泛应用；后来Spri
g官方发布Spri
gCloud，揉合了一系列自研或其他企业捐赠的开源项目，发布微服务领域的Spri
gCloud产品。各自都有各自的优势和劣势，而
2
f随着这些年来，微服务的继续下沉sidecar和servicemesh到基础设施层，给微服务的治理带来了新的方向。微服务的关键特性服务粒度服务的粒度，切分到多大算合适太粗的话，这服务就涵盖过多的业务逻辑，从而难维护、易出错；太细了，就会搞出很多的工程，造成很大的工程维护和通信成本。主流说法是依据康威定律团队的交流机制应该和组织机构相匹配。应用到软件领域来看，如果某个应用，需要多个组织之间一起交流和修改，那么它的交流机制r