微服务架构

【目录】
一、什么是微服务
    微服务的定义
    微服务的利弊
   康威定律
二、微服务的适用性
    生产率和复杂性的关系
    系统演进
三、微服务中台战略
四、微服务总体技术架构

----------------------------------------------------------

# 一、什么是微服务
----------------------------

## 微服务定义
微服务是互联网的热点，说到微服务需要谈到两个人（Martin Fowler- ThoughtWorks首席科学家、AdrianCockcroft -Netflix的前技术总监）
Martin Fowler定义微服务：
微服务一种架构风格，将单体应用划分成一组小的服务，服务之间相互协作，实现业务功能；
每个服务运行在独立的进程中，服务间采用轻量量级的通信机制协作（HTTP/JSON）；
每个服务围绕业务能力进行构建，并且能够通过自动化机制独立地部署；
保持最低限度的集中式管理，每个服务可以使用不同的语言开发，使用不同的存储技术；
参考：https://www.cnblogs.com/zgynhqf/p/5323056.html（翻译版）
         https://martinfowler.com/articles/microservices.html （原版本）
AdrianCockcroft定义微服务：
基于有界上下的，松散耦合的面向服务的架构。
总结微服务特点如下：
一组小的服务/ 独立的进程/ 轻量级通信/ 基于业务点拆分/ 独立部署/ 无集中式管理

## 微服务利与弊
优势：
强模块化边界: 微服务在组件的基础上更上一层，每一个模块以服务的方式，每一个模块以服务的方式对外提供，独立维护，模块边界明确。
可独立部署:
技术多样性: 每一个团队可以根据实际的情况选择不同的技术栈（java、nodejs）
劣势：
分布式复杂性：由原来的单一系统变为多个微服务，服务间的调用复杂，很难全局把控整个系统是如何工作的。
最终一致性: 数据分散治理，各个服务间数据如何保证一致性。
运维复杂性: 多个服务如何监控、容量规划挑战
测试复杂性: 服务分布在不同的团队，团队联合测试
系统部署依赖:

##康威定律
康威定律：1967年康威提出：设计系统的组织，其产生的设计等同于组织之内、组织之间的沟通结构（通俗理解就是组织形式等同系统设计）。
你想要什么样的系统，就应搭建什么样的团队：如果我们的团队分成前端团队，Java后台开发团队，DBA团队，运维团队，我们的系统就会长成下面的样子：

相反，如果我们的系统是按照业务边界划分的，大家按照一个业务目标去把自己的模块做出小系统，小产品的话，你的大系统就会长成下面的样子，即微服务的架构：

团队间的沟通成本有一个公式计算：沟通成本 =n(n-1)/2，沟通成本随着项目人员的增加呈指数级增长：
              5个人的项目组： 沟通渠道 = 5*(5–1)/2= 10
              15个人的项目组：沟通渠道 = 15*(15–1)/2= 105
              50个人的项目组：沟通渠道 = 50*(50-1)/2 = 1225
所以知道为什么互联网创业公司都这么小了吧，不然等CEO和所有人讲一遍创业的想法后，风投的钱都烧完了。
基于人与人之间沟通的复杂性，一个大的组织因为沟通成本/管理问题，总为被拆分成一个个小团队来达成对沟通效率的管理。
如果子系统是内聚的，和外部的沟通边界是明确的，能有效的降低沟通成本，对应的设计也会更合理高效。

通过康威定律可以总结出：
1、  要用一切手段提升沟通效率，能2个人讲清楚的事情，就不要拉更多人，每个人每个系统都有明确的分工。
2、  想要什么样的系统设计，就架构什么样的团。最好按业务来划分团队，这样能让团队自然的自治内聚，明确的业务边界会减少和外部的沟通成本，每个小团队都对自己的模块的整个生命周期负责，没有边界不清，没有无效的扯皮。
3、  做小而美的团队，人多会带来沟通的成本，让效率下降，如果2个披萨不够一个团队吃的，那么这个团队就太大了。  
4、  团队规模不要大，小团队作战为主。

#二、微服务的适用性
--------------------------

##生产率和复杂性关系
提到微服务架构时，我们常常会做的一件事情，就是会拿来与单体架构进行比较，单体架构存在如下缺点：代码维护难度大，臃肿的部署，局限的弹性与扩展能力，阻碍团队与技术革新等等；微服务架构存在如下优点：代码维护简化，可独立部署，高扩展与伸缩，自由选择开发语言等优点。那么单体架构真的如此不堪一击吗？下图来自 Martin Fowler 的文章，揭示了生产率和复杂度的一个关系：

    在复杂度较小时采用单体应用（Monolith）的生产率更高，复杂度到了一定规模时，单体应用的生产率开始急剧下降，这时对其进行微服务化的拆分才是合算的。
    所以说架构不能脱离业务场景，空谈架构绝对是耍流氓。因此架构需要服务于业务，针对不同的业务场景架构设计也会不同，架构设计不必追求高大上，简而美的架构，若能满足业务发展需求，便是好架构。
此外，好的架构不完全是设计出来的，随着业务量、请求量的增长，好的架构是演化而来的。微服务架构之所以得到广泛认可，源于对于业务多变性的不可预测，微服务架构能够不断的自演化，进而快速适应业务变化。但相对于单体架构且经过严格定义的大规模开发项目，微服务架构要求大家面对由众多小型服务所构成的复杂生态系统。
        鉴于此，如果长期业务规划不需要微服务架构或者团队不具备实施微服务一些基本的条件，不建议各位盲目迈向微服务这一新兴架构领域，或者从试点入手，逐步在团队中推行微服务架构。

##系统演进
在实际项目开发中，团队成员了解微服务架构，系统也可以使用微服务架构设计，是一开始就设计成微服务形式还是单体应用呢？

单块优先原则，刚开始并不推荐直接上微服务架构，因为在刚开始并不一定对问题领域很理解，花了很多的精力开发微服务，微服务前期投入较高，系统并没有受到业务验证的，失败的风险成本较高.
随着单体应用的完善，业务的不断的发展，团队对问题领域的认识不断的清晰，当单体应用已不能满足业务，此时可以考虑逐步抽离核心的模块。

#三、微服务中台战略
-----------------------
2015年底，阿里巴巴启动中台战略，构建符合DT时代的更具创新性、灵活性的“大中台、小前台”的组织机制和业务机制。中台战略启动之前，马云等高管曾经到芬兰supercell游戏公司参观，2015年全球top10 app游戏中该公司占据大半江山，马云对supercell公司所构建的中台能力给予很高的评价，正是由于supercell公司的中台支撑了该公司迭代创新、快速试错的能力。
“大中台、小前台”大中台强调强化技术中台和业务中台和基础设施，小前台指前端业务更灵活，根据市场变化，业务需求，能快速演化出新的前台，最终的目标是赋能业务持续创新,产生不同的业务模式,快速响应业务需求。
参考：https://zhuanlan.zhihu.com/p/30340662

如果对alibaba中台战略感兴趣，可以买本书来看看《企业IT架构转型之道-阿里巴巴中台战略思想与架构实战》，前几章讲的不错。

#微服务总体技术架构
----------------------------------

上图为微服务架构的一个比较通用的总体技术架构图，一般来说最上层为接入层，负载均衡器，负责把外部的流量接入到内部平台上来，
最下面一层为基础设备层，主要是运维团队维护，提供最基础的服务：计算、网络、存储、安全的管理，这两层是系统的基础设施，与运维团队更加紧密。
中间四层为微服务的密切相关，网关层：外部流量接入后，首先进入的就是网关层，网关层在微服务体系中有非常重要的地位，负责反向路由、熔断，服务降级等功能。
业务服务层：简单的分为两层，聚合服务对原子服务进行聚合裁减对外提供业务能力。
支持服务：注册发现服务、配置中心、消息队列、 缓存等服务。
单体架构&微服务架构&中台服务架构
开门见山，一图胜千言，先来看看单体架构跟微服务架构的区别？ 单体服务架构，将所有的功能模块(service)打包到一起并放在一个web容器中运行。 微服务架构，就是将复杂臃肿的单体应用进行...
--------------------- 
作者：pittjunson 
来源：CSDN 
原文：https://blog.csdn.net/weixin_42255229/article/details/80411184?utm_source=copy 
版权声明：本文为博主原创文章，转载请附上博文链接！