这2年，各种技术大会提服务 格的多，提微服务的极少。原因是微服务在实施中受到一系列困难与挑战。
数百&上千个微服务在同一个注册中心下 状结构相互调用，其调用链路，可靠性，开发难度挑战极大。
康威定律
1.设计系统的架构受制于产生这些设计的组织的沟通结构。
2.跨部门或者团队沟通是非常难的。
3.沟通的问题会带来系统设计的问题，从而影响整个系统的开发效率和最终产品结果。因为设计，沟通，联调成本很高。
康威定律阐述了组织边界决定技术边界。
微服务实施中，逐渐受到组织边界，业务发展，服务治理，开发效率，代码维护的制约。
单体架构易于提炼共性，而微服务架构更强调个性，不利于提练共性。好的架构要根据业务落地生根长期演化而来。
单体服务
单体可以描述为一种自给自足的系统。在评判单体架构的优劣时，一定要考虑对应项目的复杂度，要考虑这是一个大型的单体项目，还是小型系统。
单体架构可降低沟通成本，一般来说当软件性能需求超过了单机所能满足、开发人员规模超过了2 Pizza team(6-10人)范畴下才有讨论微服务的价值。
单体服务优势：
1对于小型系统，单台机器足以支撑其良好运行系统。
2易于开发，测试，部署
3系统中各个功能，模块、方法的调用都是进程内的调用，不会发生进程之间的通信，因此运行效率是最高的。
单体服务劣势：
1大型复杂的服务，容错性差，一旦挂掉整个业务线都受到影响，
2在开发过程中，各种业务功能混杂在一块，对测试开发都不友好
3从团队管理的角度来看，一群人都扑在一个系统不利于分工明确，如果划分为多个微服务可以让专人专门负责某一块，职责清晰
单体服务并不是没有合适的应用场景。不复杂的系统或单机性能完全满足的大型单体系统依然以其管理的方便性，稳定性存在各行各业中。
微服务架构
微服务是一种软件开发架构风格，是SOA的一种变体，最早2005年提出，崛起是在2014.
1微服务是一种通过多个小型服务组合起来构建的单个应用架构风格，这些服务围绕业务能力而非特定的技术标准来构建。
2各个服务可以采用不同的语言、不同存储等。
3通过轻量级的通信机制和自动化部署机制实现通信和运维。
难度: 远程方法调用和本地方法调用
调用远程方法和调用本地方法虽然一词之分，但就其复杂度而言不可同日而语
远程需要考虑的问题服务发现，有多少服务（负载均衡） 异常处理（熔断，隔离，降级），方法的参数与结果如何协商成互认的格式（序列化），服务权限（认证，授权）等等
特征：
1围绕业务能力构建：团队的结构 规模 能力 会产生对应结构
2分散治理：独立实现的权利 不同的技术语言
3产品化思维：团队应该为整个生命周期负责，开发人员不仅知道如何开发还得知道它如何运作 用户如何反馈，乃至售后如何支持
4容错性设计：不要虚幻地追求服务的永远稳定，接受出错的现实，在微服务设计中，要有能够对依赖的服务进行快速故障检测
5基础设施自动化：微服务架构下运维数量是单体架构运维数量的几倍，这也是服务 格的流行原因
按康威定律的启示(控制沟通成本)
1随组织内人员规模增多后再考虑微服务架构
2小团队或独立小业务仍可在团队内部采用单体架构
3跨团队的微服务调用要有明确的服务调用入口边界，不可形成N*N调用 络，所有服务都暴露，一旦某个设计不合理的服务接口被外部所依赖，则沟通和调整很艰难
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！