微服务架构，已经被认可了5年左右，是未来软件架构的方向。大家需要明白的是为什么需要服务。比如微服务架构给企业带来什么价值？缺点是什么？这里简单说一下微服务架构，主要是理解Why：为什么一定要面向服务？一、对微服务架构的理解1.1微服务架构服务架构主要是因为多了一个“微”。亚马逊有一个粗略的定义：一个微服务应用项目的所有开发、测试、运维加起来大概需要6到8个人，一次聚餐只需要两个披萨。反例：不是由Service类组成，而是发布为服务的应用项目就是微服务。这个划分太小了，对微服务的理解很片面。杭州的一家大型金融公司，曾经做的非常细致，导致运维测试成本巨大。开始分开折腾...1.2为什么需要微服务？从SOA架构->微服务架构，你要明白为什么微服务架构会被广泛提及和实践。它解决什么问题，带来什么价值？传统企业或者很多企业的软件大多是一个以上的系统，是一堆堆独立的大系统。总体问题是：可扩展性差，可靠性低，维护成本高，重复的轮子很多。那么，针对这些问题，可以想到的解决方案是：基于组件的服务微服务架构，将各个组件或模块分散到各个服务中。解耦整个系统。微服务架构最强调的是业务系统需要完全组件化和服务化。什么是组件化？组件化是指将一个庞大的系统按照一定的业务或技术维度拆分成独立的组件。目的是分而治之，为了可重用性，并减少耦合。比如按照技术维度：搜索组件、缓存组件；从业务维度看：用户中心、支付中心等组件化，是不是中间平台？阿里巴巴提出大中平台，小前台；也就是将组件化、插件化、服务化的解决方案做到极致。通过产品线的公共业务或技术下沉，形成各种技术或业务平台（图片来自漫画程序员小辉）2.服务化前的问题2.1不服务化不代表不分布式或集群分布式，它是Multiple实例提供相同的服务。例如，在多个地方火车站，多台机器提供取票服务。多个地方，比如北京、上海，都是多个机房，多个票务服务一起集群，形成分布式服务。那么什么是面向服务呢？服务至上，强调“供应”！核心是不同服务之间的通信。是一个以服务为中心的解决方案：服务注册、服务发布、服务调用、服务监控、服务负载均衡等。2.2没有服务的架构问题没有服务之前，举个例子，会更形象：假设有一个取票服务、票务服务、换座服务都需要验证用户身份的真实性，所以会存在以下问题：票务服务->调用用户DB代码->用户DB票务服务->调用用户DB代码->用户DB换座服务->调用用户DB代码->用户DB明显的问题是：代码重复：不同业务访问DB的userDAO代码逻辑相同。并且每个服务的代码由不同的人维护。可维护性低：由不同的人维护；异地维护；每次更改DB字段或移动数据库时，都会修改所有业务。自然而然，也有DB访问耦合的解决方案：lib。为每个业务方维护一个user-DAO-lib1.0.0发布包。解决问题、引入新问题、升级lib都是巨大而冗长的问题。比如小李就是user-DAO-lib的维护者，曾经写过一个隐藏的bug。user-lib升级到1.0.1版本，推了几十个业务方，用了一个月左右的时间完成了升级。然后跑了几天就出现了这个bug。考虑到升级修复或回滚的巨大成本，基于服务，可以完美解决问题。3、服务化后的收益如图。Post文章服务调用Video视频服务，需要通过顶层Service相互调用。服务变化明显：DB隔离：这样可以屏蔽底层的细节设计，后续添加其他存储缓存业务调用方不会察觉。服务间通信：具体协议可以是RPC/HTTP等服务。好处：调用简单：访问用户服务不需要写相同的代码，只需要调用一个服务就可以代码复用：区别于lib形式的代码复用原因是服务化解决了业务隔离，数据库解耦，等通过沟通。四、不可否认的微服务架构或服务化带来的新问题1、小系统和业务不复杂的系统不需要微服务架构。微服务架构会带来一定的复杂性，这是一套完整的服务治理方案。2.多模块数据库，分布式事务是一个挑战。3.开发过程，增加了测试的复杂性，有利也有弊。具体场景和具体选择5.总结这个总结不是关于how，而是why。只有明白为什么我们才能做得更好。从为什么是面向服务的？微服务架构为何如此火爆：微服务扩展性高，微服务可靠性高，微服务维护成本小，微服务几乎没有重复的轮子，微服务直接调用简单的微服务，业务隔离，微服务，数据库解决方案耦合等参考资料互联网架构，为什么要面向服务？https://mp.weixin.qq.com/s/S6ga8y88qaAjbKjuKMrowQhttps://zh.wikipedia.org/zh-sg/%E5%BE%AE%E6%9C%8D%E5%8B%99
