<From http://36kr.com/p/5042735.html>
Today's sharing mainly comes from my previous work experience and my usual study summary and thinking.
Editor's note: The sharer of this article, Yang Bo, has more than 10 years of experience in the development and architecture of Internet distributed systems. He has worked in eBay China R&D Center (eBay CDC), Ctrip, and Vipshop (VIPShop). This article is organized by Climbing Snail and Tian Guang. 36氪 reprinted with permission from the WeChat public account “Chat Chat Architecture”. Chat Architecture is a vertical community under InfoQ, which mainly focuses on the system architecture of traditional enterprises and Internet enterprises, WeChat: archtime.
Today's sharing mainly comes from my previous work experience and my usual study summary and thinking. My previous background was mainly in framework, system and platform architecture. The companies I worked for before, eBay, Ctrip, and Vipshop are all platform-based Internet companies, so today I mainly share my experience with you from the perspective of platform architecture. Everyone has a different perspective on architecture. It can be said that there are 10,000 perspectives. There are business architecture, security architecture, platform architecture, and data architecture. Participate in discussions. The topics discussed today mainly include the following:
- My understanding of schema definition
- Iteration and evolution of architecture
- Architecting for closed loop feedback
- Talk about microservices architecture and the latest topics
- Architecture and Organizational Culture Relationships
- Architect Mindset and Soft Skills
- My take on some of the architects' controversial topics
My understanding of schema definition
About 7-8 years ago, I once had a mentor who was an American counterpart of the architect. He told me that architecture is actually about discovering stakeholders and solving their concerns. Later, I read a book The book "Software System Architecture: Using Viewpoints and Perspectives to Collaborate with Stakeholders", the philosophy mentioned in it also says the same: The goal of system architecture is to address stakeholder concerns.
This is a screenshot from that book. My company used this picture to share the architecture definition before. The architecture is defined like this:
- Every system has an architecture
- Architecture consists of architectural elements and their relationships to each other
- Systems are built to meet the needs of stakeholders
- Stakeholders have their own concerns
- Schema is described by the schema document
- Architecture documents describe a range of architectural perspectives
- Each perspective addresses and corresponds to stakeholder concerns.
Before architecting a system, the architect's first task is to identify as much as possible all stakeholders, business parties, product managers, customers/users, development managers, engineers, project managers, testers, operation and maintenance personnel, product operators, etc. There may be stakeholders, and architects should fully communicate with stakeholders, deeply understand their concerns and pain points, and develop architectures to address these concerns. Architects often make the mistake of missing important stakeholders and insufficient communication, which will result in a lack of architecture that cannot meet the needs of stakeholders. Stakeholders may have conflicting concerns, such as management (manageability) vs technical side (performance), business side (more, faster and more economical) vs technical side (reliability and stability), which requires architects to balance flexibly , how to balance reflects the level and value of the architect.
The second definition of architecture is that it is primarily concerned with non-functional requirements, so-called -abilities.
This is a picture I shared in the company last time.
This is taken from a ppt of slideshare. Both figures list the non-functional concerns of the architecture. Regarding how to measure the level of the architecture, I saw a sentence last year, which had a great impact on me.
Architecture represents the significant design decisions that shape a system, wheresignificant is measured by cost of change.
Translated into Chinese, the architecture represents the design decisions that play a key role in the formation of a system, and the system is basically formed by the architecture, and the criticality here can be determined by the cost of change. This sentence was said by Grady Booch, one of the founders of UML.
Taking it a step further, the goal of architecture is to manage complexity, variability, and uncertainty to ensure that changes in one part of the architecture do not unnecessarily negatively affect other parts of the architecture during long-term system evolution. Doing so ensures agility in business and R&D efficiency, allowing volatile parts of the application to change frequently with as little impact on other parts of the application as possible.
I just entered the software development industry, and the architecture I talk about is mainly performance, high availability, and so on. Now, I have seen countless legacy systems, especially the status quo of domestic enterprise IT, legacy systems of countless coupled systems, and the poor architecture firmly restricts the business like handcuffs. The cost of upgrading and replacement is very huge, so I pay more attention to understandable, maintainability, scalability, cost. I would like to add that it is very important for a startup to get a good architect or technical CTO at the very beginning of the startup.
Iteration and evolution of architecture
I belong to the older generation of architects and started working in 1999. Professional beginners learned a lot of RUP, the concept of unified software process. The concept of RUP has a deep impact on my architecture. RUP can be summed up as three characteristics:
- Use Case and risk driven
- Architecture centric
- Iterative and incremental
RUP pays great attention to architecture and advocates architecture and risk-driven. It is necessary to start an end-to-end prototype; verify the feasibility of the architecture through stress testing, and then continue to iteratively and incrementally develop on the basis of the prototype, development->testing-> Adjust the architecture -> development, loop, as shown in the following figure:
As can be seen from the above figure, the architect should write code as much as possible, do testing, and do the architecture on paper and then leave it to the team. It is very unreliable (unless it is a very clear and mature field). In addition, those who do technical architecture tend to be a little perfectionist. At the beginning, they often like to seek greatness and perfection, ignoring the evolution and iteration of the architecture. This tendency makes it easy to form effective and rapid feedback between the product and the user, and the product does not meet the needs of end users. , continue to look at the following two figures:
第一个图是讲最小可用产品（Minimum Viable Product， MVP）理念，做出最小可用产品，尽快丢给用户试用，快速获取客户反馈，在此基础上不断迭代和演化架构和产品。第二个图是过度工程（Over Engineering）的问题，其实也是讲产品架构和用户之间没有形成有效的反馈闭环，架构师想的和客户想的不在一个方向上，通过最小可用产品，快速迭代反馈的策略，可以避免这种问题。注意，在系统真正地投入生产使用之前，再好的架构都只是假设，产品越晚被使用者使用，失败的成本和风险就越高，而小步行进，通过MVP快速实验，获取客户反馈，迭代演化产品，能有效地减少失败的成本和风险。
另外，多年的经验告诉我，架构，平台不是买来的，也不是用一个开源就能获得的，也不是设计出来，而是长期演化才能落地生根的给大家推荐两篇不错的微信文章（微信不能插入链接，根据题目Google下即可）：
- 58同城沈剑：好的架构源于不停地衍变，而非设计
- 宜人贷系统架构–高并发下的进化之路
两篇文章其实都是讲架构的迭代和演化性，值得每个架构师学习吸收。
构建闭环反馈架构
先分享一个链接，这几年对我架构影响最深的一篇文章。这篇文章是关于DevOps的，但对系统架构同样适用：http://itrevolution.com/the-three-ways-principles-underpinning-devops/
第一条道路，系统思维，开发驱动的组织机体，其能力不是制作软件，而是持续的交付客户价值，架构师需要有全局视角和系统思维（System Thinking），深入理解整个价值交付链，从业务需求、研发、测试、集成，到部署运维，这条价值链的效率并不依赖于单个或者几个环节，局部优化的结果往往是全局受损，架构师要站在系统高度去优化整个价值交付链，让企业和客户之间形成快速和高效的价值传递。
聊聊架构第二条道路，强化反馈环，任何过程改进的目标都是加强和缩短反馈环。刚入行的工程师，也是中国学生的普遍问题，就是生产运维意识不足（监控是系统反馈的重要环节）。有两种化这样讲的：
- no measurement, no improvement没有测量，就没有改进和提升
- What your measure is what you get你测量什么，就得到什么
没有监控或者监控不完善的系统相当于裸奔，开车上高速无仪表盘。有一篇很多错的关于测量驱动开发的文章，在InfoQ上的，向大家推荐：
http://www.infoq.com/cn/articles/metrics-driven-development
这篇文章提出了度量驱动开发的理念，即所谓MDD，在系统，应用和业务，通过三级监控，构建三个反馈环，在监控测量基础上持续改进系统和架构，我最近也在参考这个理念设计一个电商平台的技术架构，见下图：
这是一个电商平台的架构，整个体现了闭环架构的思想，右侧是整个平台的反馈监控环节。具体如下：
- 系统层监控计算网络存储，构建系统层的反馈环
- 应用服务层，监控业务、应用、服务，甚至整个研发流程，构建应用和服务层的反馈环
- 客户体验层，监控端用户和分析网站用户的行为，构建和客户的反馈环
下面这个图展示了系统提升和改进的一般方法：
收集->测量->调整->闭环重复，在有测量数据和反馈的基础上，系统、应用、流程和客户体验才有可能获得持续的提升和改善，否则没有数据的所谓改进只能靠拍脑袋或者说猜测。
第三条道路，鼓励勇于承担责任，冒险试错和持续提升的文化。这点是最难的，一般和企业人才密度有关。工具，技术，流程只是一个公司的冰山浮出水面的部分，而真正对企业效能影响大的则是冰山水下的部分，即企业的人和文化，架构师作为技术和架构的布道者，有责任义务鼓励和推动试错文化。
架构师要深入领会这三条道路，关注整个价值交付链的效率，关注每个环节的闭环反馈，鼓励和推动公司的试错文化，打造全系统的闭环架构（Architecting for closed loop feedback），提升整个系统效能。下图的DevOps和每日交付是每一个互联网系统架构师的梦想和努力的方向。
谈谈微服务架构微服务
我想大家都听得很多了，我本人也非常关注和推崇微服务，从技术角度讲，我认为微服务主要体现的是单一职责和关注分离的思想，从单进程模块化进一步拓展到跨进程分布式的模块化。微服务是独立的开发、测试、部署和升级单元，正如我在第一点架构定义中提到的，微服务中每个服务可以独立演变，它的cost of change比较小，整体架构比较灵活，是一种支持创新的演化式架构。去年MartinFowler写了两篇文章，给微服务泼冷水的，建议大家好好读下。
- http://martinfowler.com/bliki/MicroservicePrerequisites.html
- http://martinfowler.com/bliki/MicroservicePremium.html
这个图讲什么时候该引入微服务。微服务有额外成本的，需要搭建框架、发布、监控等基础设施。初创和小规模团队不建议采用。主要决定因素系统复杂性和团队规模，当到达一个点，单块架构严重影响效率才考虑 。另外补充一点，微服务更多是关于组织和团队，而不是技术。
架构和组织文化关系
再谈一下康威定律：
Conway’s law: Organizations which design systems[...] are constrained to produce designs which are copies of the communication structures of these organizations.
（设计系统的组织，其产生的设计和架构等价于组织间的沟通结构。 )
从单块架构到微服务架构是这个定律的很到体现。
团队是分布式的，系统架构是单块的，开发，测试，部署协调沟通成本大，严重影响效率，严重时团队之间还容易起冲突conflict。
将单块架构解耦成微服务，每个团队开发，测试和发布自己负责的微服务，互不干扰，系统效率得到提升。
可见，组织和系统架构之间有一个映射关系（1 ~ 1 mapping），两者不对齐就会出各种各样的问题，一方面，如果你的组织结构和文化结构不支持，你也无法成功建立高效的系统架构，例如集中式和严格职能（业务, Dev, QA, Deployment, Ops）的企业，很难推行微服服务和DevOps，推行Docker/PaaS平台也会比较困难，这样的组织职能之间都倾向于局部优化（local optimization），无法形成有效和合作和闭环。
反过来也是成立的，如果你的系统设计或者架构不支持，那么你就无法成功建立一个有效的组织；作为系统架构师，一定要深入领会康威定律，设计系统架构之前，先看清组织结构，也要看组织文化（民主合作式，集权式，丛林法则式，人才密度），再根据情况调整系统架构或者组织架构。
架构师心态和软技能
空杯，或者说开放心态（open minded）是一个成熟架构师的应有心态，stay hungry, stay foolish， 心态有多开放，视野就有多开阔。来自《高效能人士的七个习惯~史蒂芬~柯维》的一句话送给每一个架构师 :
如果一位具有相当聪明才智的人跟我意见不同，那么对方的主张必有我尚未体会的奥秘，值得加以了解。与人合作最重要的是，重视不同个体的不同心理、情绪与智能，以及个人眼中所见的不同世界。与所见略同的人沟通，益处不大，要有分歧才有收获。
另外再推荐一个本书《软件架构师的12项修炼》，这书中三个观点很值得每个架构师学习领会:
- soft skills are always hard than hard skills，软技能比硬技能难
- choosing relationship over correctness ，注重关系重于谁对谁错
- The politics of architecture, especially for architects who are mixed in large and medium-sized companies
Politics is the art of collaborating with others to get things done. Architecture is a social activity. In the world of technology, individualism can be easily defeated, even if your purpose is good. Technology is optimal. Technology decisions are political. Decision-making (technical decisions are political decisions), a technical product can be made by one wave of people, and another wave of people can do it. It's hard to say who does it well. No matter who does it, it puts a pair of handcuffs on the business. .
How do architects improve? Actual combat, actual combat, actual combat! Plan your career, find good teams and projects, summarize and share, learn about GitHub open source projects, participate in and create your own open source projects and products as much as possible, and accumulate them for a long time.
My take on some of the architects' controversial topics
The main controversies are two topics:
- The relationship between technology and business.
- Do architects write code?
How do architects answer such questions? A mature architect's mantra: it depends on the situation, not necessarily, yes and no, it depends. Technology and business, architects need to understand business, look at products and customers, if it is a business product, they must understand the business, if it is a technical product, not necessarily.
Architect to write code? Not necessarily. Personally, I think it is necessary to write as much as possible. If you have written code for more than ten years, with no less than 20,000 lines per year, you can play through it, so you don’t have to write it. In addition, if architects write code, they should control the degree of control, do not drill into the code head-on, spend a lot of time solving details and complex problems, and ignore global and systemic problems.
finally
I would like to say that China's current Internet development trend is very good. More and more people are joining the architect industry, which is "growing everything". But we still don't have such great architects as Martin Fowler and Adrian Cockcroft. We need to keep working hard. We expect more than ten such great figures as Martin Fowler and Adrian Cockcroft to appear in China in 10 to 20 years. We must not stop exploring, and the end of all exploration is to return to the starting point and have the first knowledge of the starting point.