微服务架构解析-优快云博客

随着互联网技术的快速发展，一些传统的IT系统支撑遇到了越来越多的问题：

系统的复杂性越来越高
线上访问压力大，交付速度无法满足业务需求
设备采购和维护成本高，测试、部署成本高
IT运维管理复杂，构建一只全功能团队困难

针对上述问题，传统的单体结构已经不再适用于复杂度日益渐增的产品，因此一种新的软件架构提供了解决方案——微服务。

什么是微服务

微服务架构是一种架构风格，就如MVC、分层架构一般，它有六个特点：

一组小的服务：原来单块架构将所有的业务能力打包在一个单块应用当中的，而微服务主张将这些单块应用拆成一个个小的独立的服务。
独立的进程：正如Java应用程序可以部署在Tomcat容器中，容器本身也是一个独立的进程，微服务可以部署在容器中，容器可以部署在物理机上，以进程的方式去横向扩展微服务
轻量级通信：主张轻量级协议，如http
基于业务能力构建微服务
独立部署：微服务拆分后由每个团队各自维护，可以独立进行开发、演化、部署，各部门之间不需要太多的协调，大大提高的团队的迭代效率。
无集中式管理：原来的架构是有独立的架构团队制定标准，统一技术栈、统一存储方式。而微服务架构则主张每个团队选择其最能解决当前问题的技术栈及存储机制。

用一句话来概括微服务就是基于有界上下文的（局部状态，每个团队可以维护自己的数据源，服务演化速度比较快，对服务支持更敏捷），松散耦合（服务之间不能强依赖）的面向服务的架构。

微服务优缺点

架构最重要的职责就是权衡，了解微服务的优缺点才能更好地使用微服务。

优势

强模块化边界：组件、类库以服务的方式进行调用，可以直接调用服务，而不需要引入包（程序实体）
可独立部署：各团队可单独对服务进行维护部署，不需要涉及其他团队进行协同
技术多样性：分散式治理，各团队可根据业务实际情况选择最优技术栈

弊端

分布式复杂性：服务之间相互沟通协作实现业务功能，清晰理解整个完整架构的难度上升
最终一致性：需要维护不同数据源的状态同步问题
运维复杂性：运维团队需要引入监控、进行容量规划以保证服务的可靠性、稳定性，运维难度上升
测试复杂性：各服务分散在各个团队，一个完整的业务功能测试可能需要很多团队联合测试

微服务不是银弹，如果一个单块应用尚且搞不定，更别指望微服务能拯救你。

康威法则与微服务的关系

Organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations.

上述这句话的意思是设计系统的组织，其产生的架构设计等价于组织间的沟通结构。因此技术架构和组织架构的关系是强相关的，这也解释了为什么单块应用随着系统复杂性越来越高变得不再适用。

在业务初期，开发的系统是简单的单块应用，但随着业务量变大，团队规模变大，单块应用架构和多团队之间产生了不匹配的情况，也就是违反了康威法则。

什么时间段引入微服务

在了解康威法则后，什么时候是引入微服务架构是最优时间点呢，是越早引入越好吗？

答案当然不是。通常情况下，业务初期开发的系统只是为了验证商业模式，并不是很复杂，因此并不推荐一开始使用微服务。

微服务适用性

下面这张图表的横坐标表示生产力，纵坐标表示系统复杂性，很准确地描述了微服务的适用性。

微服务有基础设施要求需要一定的前期投资，而单块应用不需要很大投入就能交付基础功能。

随着业务量变大，团队规模和单块应用的矛盾凸显违反了康威法则，生产力会随着业务复杂性下降，这时候要考虑微服务解决问题的交叉点（这个交叉点意味着单块应用已不再合适，这个时间点的确定需要架构师综合权衡）

单块优先

上述这张图表很清楚的展示了架构是通过设计出来和还是演化出来的两个过程。

在业务初期，架构师还对业务问题的领域模型不清晰，一开始直接采用微服务架构进行服务拆分是冒险的。

而如果一开始就采用单块应用的模式，随着业务的发展，架构师对业务问题领域模型越来越清晰，这个时候就能准确地找到系统的瓶颈对功能模块进行合理拆分。

微服务组织架构

康威法则是微服务的组织原理，因此可以说微服务架构本质上是组织架构的重组，那么什么样的组织架构更适合微服务架构？

首先来看看传统企业中是如何组织团队的，下面这个图表为传统职能型的团队架构，横坐标标识业务价值流的交付过程，一般来说一个业务需求先由产品开始到研发到DBA最后上线运维，纵坐标表示业务能力，在传统的企业当中团队划分方式是严格按照职能的。当有项目的时候，会从各个职能团队进行抽调组成交付团队，等到项目完成后再回归各自的职能团队。这种传统的职能划分团队的方式有两个缺点：