大部分工程师包括架构师都是从微观架构起步的。微观架构指在一个局部的领域达到设计及实现的合理性,比如写一个排序的程序,达到时间空间复杂性的合理性,同时在代码的易读性、扩展性及可维护性方面也达到一个合理的标准。但一个系统中不仅只是存在微观问题,宏观架构指一个更高层级的,全局领域的策略及架构设计,通过架构来最终达到对产品或系统在效率、成本上的收益。当系统变大之后,宏观架构的问题更突出,也更能取得收益。比如在一个互联网Web应用中,从微观角度来看,cache命中率自然越高越好,从设计上尽量让访问落在内存上。但是从宏观角度,只要SLA能得到保证,比如让70%的最近数据(可能只占1%容量)能够通过cache访问,而30%长尾数据(可能需要占用99%容量)是通过存储返回,整体开销可能会下降一个数量级,而整体性能也基本有没有大的变化。
Coding出身的工程师刚脱离微观问题的时候,可能会觉得不习惯。微观的问题容易看到成效,比如将一个程序的QPS性能提升了30%,这是一个容易度量的成绩,而宏观架构看起来很“虚”,也不容易快速产生成效,比如将一个大型传统的系统改造成一个SOA的架构。辛苦花力气改造完成,也不容易看到及度量成效,而且一些隐性的收益需要更长时间才能体现。
尽管如此,微观架构及宏观架构如同战略及战术一样,是相辅相成的。而且双方都有其重要性,无法判断一个比另外一个重要。微观方面,一个平庸工程师组成的团队,即使一个优秀的架构师从天而降,短期内也无法改变团队的成绩。同样如果技术领导只关注宏观层面问题,忽视代码细节及基本功培养,团队的产品始终难尽人满意。由于宏观架构的设计者通常在组织中拥有更大的话语权,如果对微观的问题缺少一个基本的理解,对微观的出现的矛盾不能做出正确的判断,系统的开发效率及运行效率都会出现问题。宏观方面,一群优秀的工程师,如果能聚集到一个优秀设计架构的平台上,肯定如虎添翼。在一个团队中,宏观架构及微观架构的人员需要达到一个合理的比例。
以下是以前思考的一些断言,你判断是这些是宏观还是微观架构?
- The C10k problem refers to the problem of optimising server software to handle a large number of clients at the same time (hence the name C10k – concurrent ten thousand connections). The problem of web server optimisation has been studied because a number of factors must be considered to allow a web server to support many clients. This can involve a combination of operating system constraints and web server software limitations.
- The goal of SPDY is to reduce web page load time. This is achieved by prioritizing and multiplexing the transfer of web page subresources so that only one connection per client is required. Transmission headers are gzip-or DEFLATE-compressed by design. Moreover, servers may hint or even push content instead of awaiting individual requests for each resource of a web page. SPDY可以用作HTTP RPC一个高效替代
- 普通硬盘的访问延时是SSD的5-500倍
- 使用event方式事件模型的编程模型可以极大降低线程之间context switch的开销
- Code review is systematic examination of computer source code. It is intended to find and fix mistakes overlooked in the initial development phase.
- 在大型系统中,模块之间组合的架构可以看出整体架构的优良及团队效率
- 移动app方向,未来一段时间仍然主要以产品模式及运营方向主导,技术驱动领域主要集中在快速迭代能力
- 虽然大数据是以后的一个发展趋势,但是数据挖掘的大部分场景还只是浅层次的应用,系统瓶颈不在挖掘能力,而是在应用能力上
SOA?
1 微观
2 微观
3 微观
4 微观
5 宏观
6 宏观
7 宏观
8 宏观
1 宏观
2 微观
3 微观
4 微观
5 宏观
6 宏观
7 宏观 部分同意,类似Siri这一类的应用,还是要深挖技术的,尤其是需要结合服务器端(or 时髦的云端)的能力来弥补客户端的不足(电力,屏幕…),深深需要技术的强力支撑!
8 宏观
只有微观则莽(http://baike.baidu.com/view/2267363.htm ), 只有宏观则虚(飘飘乎乎, 不接地气), 只有两者相结合, 才能最有效果!
宏观架构看起来很“虚”,也不容易快速产生成效??这句不晓得从何而来
SOA 架构 写成 SAO 架构了。呵呵。
本应该关注宏观架构的过度关注微观架构就又变回普通工程师了。
什么时候领导能放心让手下去做具体工作,这个团队才算正常运作