真是绝了！git 标星 19
本文尝试从方法论进行梳理，然后从微服务架构切入，进行深度演绎，最后辅以大量的业务场景实战，让读者更好地理解和消化“架构”的意义和构建方法，是抽象理论和实践经验相结合的佳作。
本文集国内众多资深架构师智慧之所长，对架构方法论、微服务架构、业务架构、性能优化 4 个方面进行了详细讲解。学习架构知识就需要参考这样的好文，建议希望深入学习架构知识的朋友们阅读这本宝典。
希望本文能够帮大家把这种架构思维给建立起来，不断地提升自己的技术深度和广度，让自己变得更有价值，更希望本文能够帮助到大家的学习，多多转发让更多的人受益！！！
目录
==
主要内容
====
本文将分为四部分给大家深入介绍要想成为架构师需要具备什么能力和技能：
第 1 篇架构方法论；
1.有关架构的概念认知；架构是一个综合性很强的专业领域。软件架构的作用在本质上与建筑物中基本架构所起的作用是一样的°。要成为一名合格的架构师，不仅要具备计算机科学或软件工程领域的知识，最好还要深入学习哲学、数学，并了解一些建筑学常识，尽量拓宽视野，一般情况下，需要经历程序员、软件设计师等阶段，最后成为软件架构师。
架构并不神秘，也不高高在上，它就在实践中，只要留心学习、主动思考，在架构领域是大有可为的。
2 以终为始的架构设计；综上所述，软件架构工作看似简单，其实不然。系统化思考有助于理清软件架构流程及从客户价值出发，识别用户、设定 SLA 可以帮助软件架构设计人员和研发人员避免在技术纷繁复杂的跋涉中迷失而陷入“自嗨”。架构是演进而来的，架构包含了一系列的决策和若干组成，进行架构设计时应该从全局视角看问题。
3 闭环架构方法；本章总结了软件研发型组织在产品、组织、流程和架构方面经常需要关注的一些反馈环(feedback loop)，以及强化这些反馈环所需要的支撑性技术和架构手段，希望对软件研发型组织在这些方面的改进提升有一定的指导价值。另外，希望本章分享的内容对研发工程师和架构师建立闭环反馈和 DevOps 意识有一定的指导意义。
本章内容主要基于对之前工作的总结和思考，目的有两方面，一方面是梳理自己的思路并做些沉淀，另一方面是抛砖引玉，激发大家的进一步思考。如有理解不当、有失偏颇之处，还请各位不吝指教。
本章的内容主要针对提供 SaaS 服务的软件研发型组织，其他涉及 IT 系统的组织类型也可从中借鉴。
4 复杂与架构演进的关系；路漫漫其修远兮，处理软件系统的复杂性是一个永恒的话题。虽然应对复杂性的方法(包括工具与研发过程）层出不穷，但软件系统的复杂度也会随着技术发展而衍变。这二者之间的关系就是软件系统中的道与魔，虽然“道高一尺，魔高一丈”，但我们总还是需要使出浑身解数来为软件“卫道除魔”。没有什么捷径可走，唯一能做的就是在明了软件复杂产生的原因之后，积极寻求应对的办法，如诊病一般，找准病因，然后对症下药。
5 架构师的核心能力；在多年的架构工作中，我经常反问自己什么才是自己应该做的事，如何才能做好架构工作。本章意在从职责、核心能力、能力修炼等方面总结自己的经验和对架构工作的看法。做架构师要仰望星空、匍匐前行。仰望的是远景和方向，匍匐是要对业务和具体的研发有掌控
，避免成为空中楼阁一般的“PPT 架构师”。
**第 2 篇面向架构的架构（微服务）；**微服务架构是一种架构模式，也是一种很有趣的思维方式，其主要作用是将功能分解到离散的各个服务中，从而降低系统的耦合性，并提供更加灵活的服务支持。微服务架构中的每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通，每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。本篇会从微服务的概念到实施为大家介绍微服务的各个细节及微服务自身的优缺点。
6 快速继承微服务实践；总体来看，微服务有着其自身的优势，也一样有着需要面对的问题。分布式系统所带来的复杂性在微服务架构模式下并不能被忽略，而且由于服务切分带来的进一步分布式协作对工程化实践提出了更多的挑战。微服务除了要具备基本服务化的能力，还要在分布式系统固有的性能、分区容错性、一致性、安全等问题上小心应对。同时，微服务对生产环境就绪功能提出更高的要求，覆盖从开发、测试、发布、运维、监控、下线等完整生命周期，尤其在提高开发效率、服务治理、监控、Cloud Native 架构模式、资源虚拟化自动化水平上需要做更多的工作以更好地落地微服务。
7 微服务架构下的事务处理；本章主要介绍了分布式系统的 CAP 理论，同时总结并对比了几种分布式分解方案的优缺点。分布式事务本身是一个技术难题，没有一种完美的方案可以应对所有场景，都要根据具体的业务场景来抉择。
8 微服务架构模式与实践；总的来说，好雨 Rainbond 在 Service Mesh 微服务架构方面的核心原则在于开放，通过各类优秀解决方案标准化的接入来为用户提供开箱即用、强大简单的微服务体验。
9 微服务与 DevOps 架构实践；DevOps 是按业务来组织团队的，团队包含设计、开发、测试、运维等人员，这样一方面可以有效减少服务内部修改所产生的内耗;另一方面，团队边界可以变得更为清晰。
DevOps 实际是一种文化上的变迁，打破了传统开发与运维之间的壁垒，帮助组织形成从开发、测试到部署、运维这样一个全功能化的高效团队。
10 基于云的微服务架构；在微服务架构下可以按功能和职责充分分解服务，解耦依赖，单个服务易于开发和维护，可以实现更短的开发迭代周期，促进敏捷开发和持续部署。但我们也要充分认识到微服务有着分布式架构固有特点带来的复杂性，大量服务之间的通信对应用的集成测试、稳定性、运维和监控提出了更高的要求，CAР理论的约束对数据的一致性也带来了更大的挑战。微服务架构对基础设施的投入要求很高，简单应用采用单体架构更经济有效，大型复杂应用采用微服务架构才能体现出投入的价值。
11Service Fabric 平台架构解析；Service Fabric 作为微软研发和使用超过 10 年的系统托管平台，具有鲜明的特点、完善的功能和强大的特性。
不仅提供了特有的编程模式让开发面向微服务架构的应用变得轻而易举，还可以通过来宾或容器模式让遗留系统享受到 Service Fabric 的强大能力。
第 3 篇面向业务的架构；
12 如何搭建高可伸缩的移动电商架构。本章介绍了可伸缩的移动电商架构，包括移动端混合架构、服务器端的 SOA 架构、基于容器的虚拟化，以及如何应用弹性云等技术应对电商大流量、高并发的大型促销场景，希望可以为你搭建高可伸缩的移动电商架构带来启发。
13 消费信贷系统“白付美”是如何持续优化的；“白付美”的技术架构从简单的单体应用扩展为微服务架构，分工越来越细，对专业程度的要求也越来越高，这就需要我们沉淀出核心的服务能力来快速支撑业务的发展，且要保障系统的稳定支撑，这给我们带来的挑战是非常大的。
截至目前，“白付美”已为数百万用户提供了便利的服务，产生了数千万的账单，且经历了多次集团大促活动，服务的用户越来越多，我们身上的担子也越来越重，后续要做的事情也越来越难。
14 美丽联合集团支付系统架构演进，通过业务的梳理、系统边界的拆分、业务建模等处理，我们完成了对支付系统 2.0 的架构升级，进而能够对业务提供更加高效、稳定、专业的支撑，并提升资金的核算和管控能力。
在未来的发展中，上层支付收单业务会针对电商特色做更多的业务支持，下层资金结算会提供准确无误的核算闭环，同时需要对平台的性能容量寻找一切可改进的地方，持续不断地进行优化。资金无小事，如何提升支付系统的稳定性也必定是重点考虑的方向。
15 金融撮合架构，通过了解现行电子商品交易市场的交易制度和交易流程，熟悉电子商品交易市场撮合订单的方式与机制，并将其转换为详细的流程框图，为设计撮合系统打下了基础。
本章从交易机制中抽象出撮合系统的需求，将系统分为多个功能模块进行详细架构和设计，同时为了构建一个高性能、高可靠性和高扩展性的交易撮合系统，基于多层分布式体系及 J2EE 技术进行设计与实现，且采用了最新的内存撮合技术，利用多级存储模式提高系统运行效率。随着电子商品交易市场的日益扩大及股民对系统性能要求越来越高，如何构建一个高性能的撮合交易系统是电子商品交易市场需要进一步研究的。
本章通过构建一个基于多层分布式架构的电子商品交易撮合系统来模拟电子商品交易市场，借此充分展示了电子商品交易市场的运作模式，为进一步的研究提供了基础。
评论