服务架构演进-单体与微服务

以下内容来自于日常学习总结（凤凰架构），记录成长之路

康威定律

设计系统的架构受制于产生这些设计的组织的沟通结构。跨部门或者团队沟通是非常难的。沟通的问题会带来系统设计的问题，从而影响整个系统的开发效率和最终产品结果

好的架构应该根据业务落地生根长期演化而来

单体

单体可以描述为一种自给自足的系统。在批判单体架构的优劣时，一定要考虑对应项目的复杂度，要考虑这是一个大型的单体项目，还是小型系统。在与那些爱赶技术潮流却不顾需求现状的微服务吹捧者讨论架构问题一定要保持头脑清醒。

一般来说当软件性能需求超过了单机所能满足、开发人员规模超过了2 Pizza team范畴下才有讨论微服务的价值。

单体服务的优势：

对于小型系统，单台机器足以支撑其良好运行系统。不仅易于开发，测试，部署，且由于系统中各个功能，模块、方法的调用都是进程内的调用，不会发生进程之间的通信，因此连运行效率也是最高的

单体服务的劣势：

大型复杂的服务，容错性差，一旦挂掉整个业务线都受到影响，其次在开发过程中，各种业务功能混杂在一块，对测试开发都不友好，从团队管理的角度来看，一群人都扑在一个系统很难做到分工明确，如果划分为多个微服务可以让专人专门负责某一块，职责清晰。

单体服务并不是没有合适的应用场景。不复杂的系统或单机性能完全满足的大型单体系统依然以其管理的方便性，稳定性存在各行各业中。

服务拆分：

内部拆分，即还是统一套程序 但是按功能或者业务划分成各个模块

横向

纵向

远程方法调用和本地方法调用

调用远程方法和调用本地方法虽然一词之分，但就其复杂度而言不可同日而语

远程需要考虑的问题 服务发现，有多少服务（负载均衡） 异常处理（熔断，隔离，降级），方法的参数与结果如何协商成互认的格式（序列化），服务权限（认证，授权）等等

微服务架构

微服务是一种软件开发架构风格，是SOA的一种变体，最早2005年提出，崛起是在2014

微服务是一种通过多个小型服务组合起来构建的单个应用架构风格，这些服务围绕业务能力而非特定的技术标准来构建。各个服务可以采用不同的语言、不同存储等。通过轻量级的通信机制和自动化部署机制实现通信和运维。

特征：

围绕业务能力构建：团队的结构 规模 能力 会产生对应结构

分散治理：独立实现的权利 不同的技术语言

产品化思维：团队应该为整个生命周期负责，开发人员不仅知道如何开发还得知道它如何运作 用户如何反馈，乃至售后如何支持

数据去中心化：

容错性设计：不要虚幻的追求服务的永远稳定，接受出错的现实，在微服务设计中，要有能够对依赖的服务进行快速故障检测

演进性设计：

基础设施自动化：微服务架构下运维数量是单体架构运维数量的数量级倍