04-24 17:54
|
'Architecture'에 해당되는 글 3건[Architecture] Microservices Pattern.ITWeb/스크랩 2021. 8. 19. 10:35https://microservices.io/patterns/index.html Microservices Pattern: A pattern language for microservices Microservices.io is brought to you by Chris Richardson. Experienced software architect, author of POJOs in Action, the creator of the original CloudFoundry.com, and the author of Microservices patterns. Chris helps clients around the world adopt the micros microservices.io
[Elasticsearch] Shard Allocation Filtering 설정 시 주의사항. (on 2.1)Elastic/Elasticsearch 2015. 12. 10. 11:01hot-warm architecture 구성시 경험했던 팁 공유 합니다. 아주 사소한 팁입니다. 원문링크) https://www.elastic.co/guide/en/elasticsearch/reference/2.1/shard-allocation-filtering.html index settings 기능을 이용해서 "index.routing.allocation.{attribute}.{attribute}" 설정을 하게 됩니다. 이 과정에서 사용하는 REST API 가 두 가지가 있습니다. [_settings API] $ curl -XPUT "http://localhost:9200/db/_settings" -d' { "index.routing.allocation.require.box_type":"warm" }' [Request body에 settings] $ curl -XPUT "http://localhost:9200/db" -d' { "settings": { "index.routing.allocation.require.box_type":"warm" } }' 개인적으로는 위 두 가지 방식이 다 동작해야 한다고 생각해서 실행을 시켰습니다. 해보시면 아시겠지만 아래 방식은 index_already_exists_exception 에러가 발생을 합니다. Elasticsearch에 확인해본 결과로는 에러 메시지를 잘못 return 해준 경우라고 하내요. 즉, trivial 정도의 bug(?) 라고 봐도 될 것 같긴 합니다. 어쨌든 수정할 거라고 하니 나중에는 반영 되리라 기대 합니다. 그리고 http method 사용시 보시면 아시겠지만 PUT method 를 사용하셔야 합니다. 제가 POST 를 사용했는데요. 이 경우에는 PUT 을 사용하는게 맞다고 합니다. 제가 삽질한 이유가 되겠습니다. ㅡ.ㅡ;; [펌]Software architectureLegacy 2009. 10. 19. 23:31원본글 : http://en.wikipedia.org/wiki/Software_architecture
연관글 : http://en.wikipedia.org/wiki/Zachman_Framework Software architectureFrom Wikipedia, the free encyclopedia
The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships between them. The term also refers to documentation of a system's software architecture. Documenting software architecture facilitates communication between stakeholders, documents early decisions about high-level design, and allows reuse of design components and patterns between projects.[1]
[edit] OverviewThe field of computer science has come across problems associated with complexity since its formation.[2] Earlier problems of complexity were solved by developers by choosing the right data structures, developing algorithms, and by applying the concept of separation of concerns. Although the term “software architecture” is relatively new to the industry, the fundamental principles of the field have been applied sporadically by software engineering pioneers since the mid 1980s. Early attempts to capture and explain software architecture of a system were imprecise and disorganized, often characterized by a set of box-and-line diagrams.[3] During the 1990’s there was a concentrated effort to define and codify fundamental aspects of the discipline. Initial sets of design patterns, styles, best practices, description languages, and formal logic were developed during that time.[who?] The software architecture discipline is centered on the idea of reducing complexity through abstraction and separation of concerns. To date there is still no agreement on the precise definition of the term “software architecture”.[4] As a maturing discipline with no clear rules on the right way to build a system, designing software architecture is still a mix of art and science. The “art” aspect of software architecture is because a commercial software system supports some aspect of a business or a mission. How a system supports key business drivers is described via scenarios as non-functional requirements of a system, also known as quality attributes, determine how a system will behave.[5] Every system is unique due to the nature of the business drivers it supports, as such the degree of quality attributes exhibited by a system such as fault-tolerance, backward compatibility, extensibility, reliability, maintainability, availability, security, usability, and such other –ilities will vary with each implementation.[5] To bring a software architecture user's perspective into the software architecture, it can be said that software architecture gives the direction to take steps and do the tasks involved in each such user's speciality area and interest e.g. the stake holders of software systems, the software developer, the software system operational support group, the software maintenance specialists, the deployer, the tester and also the business end user[citation needed]. In this sense software architecture is really the amalgamation of the multiple perspectives a system always embodies. The fact that those several different perspectives can be put together into a software architecture stands as the vindication of the need and justification of creation of software architecture before the software development in a project attains maturity. [edit] HistoryThe origin of software architecture as a concept was first identified in the research work of Edsger Dijkstra in 1968 and David Parnas in the early 1970s. These scientists emphasized that the structure of a software system matters and getting the structure right is critical. The study of the field increased in popularity since the early 1990s with research work concentrating on architectural styles (patterns), architecture description languages, architecture documentation, and formal methods[6]. Research institutions have played a prominent role in furthering software architecture as a discipline. Mary Shaw and David Garlan of Carnegie Mellon wrote a book titled Software Architecture: Perspectives on an Emerging Discipline in 1996, which brought forward the concepts in Software Architecture, such as components, connectors, styles and so on. The University of California, Irvine's Institute for Software Research's efforts in software architecture research is directed primarily in architectural styles, architecture description languages, and dynamic architectures. The IEEE 1471: ANSI/IEEE 1471-2000: Recommended Practice for Architecture Description of Software-Intensive Systems is the first formal standard in the area of software architecture, and was adopted in 2007 by ISO as ISO/IEC 42010:2007. [edit] Software architecture topics[edit] Architecture description languagesArchitecture description languages (ADLs) are used to describe a Software Architecture. Several different ADLs have been developed by different organizations, including AADL (SAE standard), Wright (developed by Carnegie Mellon), Acme (developed by Carnegie Mellon), xADL (developed by UCI), Darwin (developed by Imperial College London), DAOP-ADL (developed by University of Málaga). Common elements of an ADL are component, connector and configuration. [edit] ViewsSoftware architecture is commonly organized in views[7], which are analogous to the different types of blueprints made in building architecture. Within the ontology established by ANSI/IEEE 1471-2000, views are instances of viewpoints, where a viewpoint exists to describe the architecture in question from the perspective of a given set of stakeholders and their concerns. Some possible views (actually, viewpoints in the 1471 ontology) are:
Several languages for describing software architectures have been devised, but no consensus has yet been reached on which symbol-set and view-system should be adopted. The UML was established as a standard "to model systems (and not just software)," and thus applies to views about software architecture. Others believe that effective development of software relies on understanding unique constraints of each problem, and so universal notations are doomed because each provides a notational bias that necessarily makes the notation useless or dangerous for some set of tasks[citation needed]. They point to the proliferation of programming languages and a succession of failed attempts to impose a single 'universal language' on programmers, as proof that software thrives on diversity and not on standards. [edit] Architecture frameworksFrameworks related to the domain of software architecture are:
Other architectures such as the Zachman Framework, DODAF, and TOGAF relate to the field of Enterprise architecture. [edit] The distinction from detailed designSoftware architecture, also described as strategic design, is an activity concerned with global design constraints, such as programming paradigms, architectural styles, component-based software engineering standards, design principles, and law-governed regularities. Detailed design, also described as tactical design, is an activity concerned with local design constraints, such as design patterns, architectural patterns, programming idioms, and refactorings. According to the Intension/Locality Hypothesis[8], the distinction between strategic and tactical design is defined by the Locality Criterion[8], according to which a statement about software design is non-local if and only if a program that satisfies it can be expanded into a program which does not. For example, the Client-Server style is architectural (strategic) because a program that is built by this principle can be expanded into a program which is not client server; for example, by adding peer-to-peer nodes. Or more simply, it is the distinction of the general from the specific. Architecture is design but not all design is architectural. In practice, the architect is the one who draws the line between software architecture (architectural design) and detailed design (non-architectural design). There aren't rules or guidelines that fit all cases. [edit] Examples of Architectural Styles / PatternsThere are many common ways of designing computer software modules and their communications, among them:
[edit] See also
[edit] References
[edit] Further reading
[edit] External links
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
