1200页Java架构面试专题及答案
小编整理不易，对这份1200页Java架构面试专题及答案感兴趣劳烦帮忙转发/点赞
百度、字节、美团等大厂常见面试题
下面总结一下粒度更细的服务带来的好处：
● 粒度更细的服务使每一个服务专注做好一件事情。每个服务完成一个单一任务，在功能不变的情况下，应用被拆分为多个可管理的服务，很好地解决了系统的复杂性问题。
● 粒度更细的服务有助于新人对工程的学习。对于一个大型的、生命周期比较长的项目，人员的流动和组织变化是经常发生的事情，而庞大的单体架构容易使模块之间相互耦合，功能界限模糊，同时增加了新人的学习成本。
● 粒度更细的服务有利于部署。对于大型单体项目，模块之间往往存在紧密的代码耦合，一个子模块的编译错误往往会导致整个应用无法构建成功，而细粒度的服务可以通过独立工程解决“牵一发而动全身”的问题。
● 粒度更细的服务具备更好的复用性。在软件领域，我们一直提倡使用复用的方式构建系统，粒度更细的服务通过独立的部署，通过声明语言无关、平台无关的标准接口（REST API、gRPC）对外暴露服务，实现了积木式的架构搭建模式，提高了软件整体的开发效率。
围绕业务划分团队
========
传统的IT企业习惯根据人员掌握的技能来划分组织。例如，熟悉前端的同事，都集中在一个前端开发团队；熟悉数据库的同事，一般都会集中在DBA（Database Administrator，数据库管理员）团队；熟悉测试的同事，专门成立一个测试团队专职做测试工作。我们习惯于将这样的团队称为“职能型组织”，它的优势是资源集中，有利于同一职能内部的专业人士交流和经验积累。
然而，职能型组织最大的问题是团队之间不容易协调利益冲突，容易形成部门墙或者叫部门壁垒。当职能部门有多个项目同时进行时，就会产生资源失衡问题，不利于各职能部门之间的沟通交流和团结协作。业务的需求变化如果牵涉多个职能型组织所负责的模块协作联调，往往会出现项目排期问题、优先级问题，对于跨地域、跨国家的组织，还会出现时差问题、沟通及文化差异问题，这个时候反而增加了团队之间的沟通和协调成本，降低了开发效率。
微服务架构更加提倡以业务为中心，强调围绕业务领域来划分团队。团队由具备不同能力象限的人员组成，而这样的全功能型团队相比职能型团队可以防止人员之间的互相扯皮、互相指责的问题。同一个团队围绕业务领域沟通效率更高，团队合作更加积极主动，有更强的主人翁意识（Ownership）。从技术的维度看，微服务架构倾向于在指定范围的“业务界限上下文”中定义标准规范的交互方式，这样能够保证业务接口（API）更加稳定，在后续服务的迭代升级过程中具备更好的业务兼容性和可演进性。
综上所述，在围绕业务构建微服务架构的时候，解决的一个本质问题就是人员分工的问题，正如康威定律所说，任何组织所设计的系统、所交付的软件产品方案在结构上都应该与该组织的沟通结构和组织方式保持一致。下面是组织结构演进示意图。
技术多样性
======
微服务架构不限定提供服务方所使用的技术栈和技术选型。微服务架构倾向于服务之间使用标准的轻量级的通信协议（HTTP）完成服务的集成和通信。例如，对于性能要求比较高、对网络通信效率比较关注的服务，可以使用C++语言构建；对于文本分析性的业务，可以采用Python脚本语言；而对于企业应用级的Web项目，使用Java语言开发比较合适。可见，每一种语言和技术都有其“擅长”的场景和适合解决的问题。
微服务架构提倡数据存储的多样性和独立性。不同的数据存储引擎有各自擅长处理的业务类型数据。对于公司的核心业务即OLTP（OnLine Transaction Processing，联机事务处理）业务，可能会采用MySQL这样的关系型数据库。关系型数据库的特点是遵循ACID原则，对事务的一致性有更好的支持，通过标准的SQL语言就可以方便地实现结构化数据的查询和更新。
在 NoSQL 数 据 库 阵 营 中 ， 对 于 日 志 数 据 ， 可 以 存 放 在Elasticsearch这样的LSM树数据结构存储引擎中，适合日志搜索、查询操作；对于分布式系统之间的共享数据，采用Redis这样的内存引擎，在读写效率、高并发性能上有更大的优势；如果是文档型数据，使用MongoDB这样的文档存储引擎更加高效便利。下面是采用不同编程语言和技术栈配合不同的数据存储类型的技术多样式示意图。
微服务架构提倡在技术多样性的场景中，选择最适合的技术栈。
微服务通过使用标准的API接口对外暴露服务，给尝试新技术提供了更加友好的架构支持。
然而，很多公司也推崇使用统一的编程语言和标准化的技术栈。
统一技术栈的优势也是明显的，首先它会带来开发效率的提升；单一技术栈的维护成本相对较低；新加入的开发人员也能够尽快适应统一的编程语言和架构风格；项目的风险相对比多技术栈有更好的可控性。
即便如此，我们说微服务架构还是向着异构化、技术多样性的趋势在发展，因为只有保持技术的多样性，才能保证技术生态的生命力。对于技术栈和技术选型来说，架构师需要一个Trade-off（权衡利弊）的过程。
去中心化
====
大型企业在集成异构系统和完成进程之间的通信时，一种传统的架构模式就是使用ESB消息总线技术，它可以完成信息路由、业务规则编排、协议转化等功能。虽然，ESB架构改变了传统软件的架构模式，消除了不同应用之间的技术差异，协调了不同应用服务的协作运行方式，实现了服务之间的集成和整合，但是，ESB架构倾向于使用集中式的架构管理模式，它本质上是一种中心化的架构。我们将这种企业服务总线或服务编配系统的方案称为“智能管道和哑终端”模式，它会导致业务逻辑的中心化和哑服务问题。
“哑终端”（Dumb Endpoint）会导致ESB消息总线过度复杂，这种中央式的架构模式存在天然的技术与业务耦合问题。业务编排和业务消息转化能力与业务功能全部集中在单一逻辑控制单元中，它并没有做很好的业务封装，而是将业务逻辑的复杂性全部传递到了消息总线中。同时，随着服务规模的扩大，中心化架构的可扩展性会成为一个极大的障碍。业务中的职责边界不清和ESB中心化的问题还会暴露性能问题，成为系统的瓶颈。
微服务架构摒弃了ESB的设计理念，在微服务架构中，服务使用智能端点（Smart Endpoint）模式。智能端点强调所有的业务逻辑应该自包含在业务内部的处理逻辑单元中，它可以确保在服务限界内服务的内聚性，而服务之间的通信应该尽量轻量化和简单化。同时，微服务使用哑管道（Dumb Pipe）通信机制，将业务无侵入的公共组件抽象出来，封装在通用的消息基础设施中（API网关、消息中间件等）。
最后
终极手撕架构师的学习笔记：分布式+微服务+开源框架+性能优化
s/4f45ff00ff254613a03fab5e56a57acb)收录**
1218
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
